Link a partner tenant to yours: the invitation, and what a connection is for — transcript

Play this as a presentation — one slide per step, with the same narration. Every word of every step is on this page.

This presentation is for you if you administer a BigLedger tenant and another business, on a tenant of its own, needs to share part of your records or you part of theirs. In about eight minutes you will know when a tenant-to-tenant link is the right tool, what it does and does not move, how the invitation and its answer work, why a connection is never deleted, and who on each side should hold the rights.

Step 1 — Decide whether a link is what you need

After this step you will know whether your situation calls for a tenant link at all. A tenant is the whole installation: companies, item master, customers, suppliers, settings. GadgetSphere keeps its three companies inside the same tenant, and a sale between them is handled inside it, as the intercompany series shows. A tenant-to-tenant link is for a different case: two businesses on separate tenants that need to refer to a slice of each other’s records. A brand principal and the franchise it supplies. A distributor and the dealer it sells through. Say GadgetSphere Distribution supplies a dealer on its own tenant. The link lets the two agree which companies, branches and items correspond: the partner’s companies and branches are readable across the link for that, and of your items the dealer sees only what you permit. Whether that dealer belongs inside your tenant or on its own is your decision, and the group set-up page says how to make it.

Reference: Setting Up a Group: What We Recommend — One tenant, or one per company

Step 2 — Know what the link does, and what it will not do

After this step you can say plainly what a connection buys you. It lets one tenant, the host, open a controlled slice to the other, the guest: a company and branch pairing, a list of items the guest may pair with its own, and a team of the partner’s users. The pairings are records kept on both sides; the team lives in your tenant. None of them moves a document. Today nothing in sales, purchasing, stock or the journals reads a tenant mapping, so pairing GadgetSphere Distribution’s laptop range with the dealer’s codes creates no order, delivery or invoice on either side. Beyond the item screen that shows a pair, the one thing that reads one is a distributor ordering integration built for a specific case, which looks up the host’s item for the guest’s before ordering. So treat the link as an agreed dictionary between two businesses: essential to the integration that uses it, silent otherwise.

Reference: T2T Admin — Where it fits

Step 3 — Send the invitation from the host

After this step the invitation exists on both sides. The host is the tenant that owns the data being shared, so GadgetSphere Distribution invites the dealer. You need the dealer’s tenant code exactly as the platform knows it: a code that does not exist is refused, and so is your own. Both tenants must already be live on the platform with a reachable database, because the invitation is written into the dealer’s database as well as yours, one after the other, yours first; if the dealer’s write fails, yours is removed again. If the platform cannot reach the other database at all, the call fails and only BigLedger can put that right. You may give the connection a name and a description, and the same words are written on both sides. Both records start as invited. Nothing e-mails or notifies the dealer, so tell their administrator that the invitation is waiting.

Reference: T2T Admin — Connecting the two sides

Step 4 — Answer it from the guest, and read the four states

After this step you can answer an invitation and read what a connection’s status means. The dealer’s administrator answers on the dealer’s own tenant with one of four responses. Accept makes both records connected. Reject makes both rejected. Later, disconnect ends the connection on both sides, and connect restores it, but only while the host still approves reconnection; the host can withdraw that approval, and then a disconnected guest cannot come back on its own. Those four words, invited, connected, rejected and disconnected, are the whole life of a connection, and mapping is possible only while it reads connected. The answer is written to the guest’s record first and the host’s second; if the host’s side cannot be written, the guest’s is put back to invited and the answer fails, so a failed answer normally leaves nothing half done; the rare case where that undo fails too is the one the next step covers.

Reference: T2T Admin — Connecting the two sides

Step 5 — Treat a connection as permanent

After this step you will not send a second invitation to a tenant that already has one. A connection record is never deleted; it only changes status. Two things follow. A tenant that rejected you still holds a record, so inviting it again is refused as already existing; if the dealer changes its mind, the way back is for the dealer to accept the invitation it still holds, not for you to send another. And the connection listing shows every record whatever its status, so invited and rejected tenants sit beside connected ones, and you read the status before you map anything to a tenant on that list. If the two sides ever show different statuses, which can happen when the second of the two writes failed and the undo failed too, nothing reconciles them: ask BigLedger to compare the two records rather than trying to answer or re-invite your way out.

Reference: T2T Admin — Troubleshooting

Step 6 — Give the right people the rights, on both sides

After this step you will know who can do what. Every tenant-link action is open to the tenant’s owner or administrator, and otherwise needs one of its permission codes: separate families for invitations, company and branch mapping, item permission and pairing on each side, external teams, roles and the audit trail. A person without the right is refused on a write; on a read there is no error, the rows come back blank, marked permission denied. So a listing empty for one colleague and full for another is a rights question before a data question. Decide on each side who owns the link, give that person the permissions, keep the list short. Every invitation, answer, company mapping and team change goes to the connection’s audit trail with who acted and when, not what was mapped; item permissions and pairs write nothing there. It is the record you will want if the businesses later disagree about who did what.

Reference: T2T Admin — Feature visibility / permissions

How the steps fit together

    flowchart TD
  s1["Step 1 — Decide whether a link is what you need"]
  s2["Step 2 — Know what the link does, and what it will not do"]
  s3["Step 3 — Send the invitation from the host"]
  s4["Step 4 — Answer it from the guest, and read the four states"]
  s5["Step 5 — Treat a connection as permanent"]
  s6["Step 6 — Give the right people the rights, on both sides"]
  s1 --> s2
  s2 --> s3
  s3 --> s4
  s4 --> s5
  s5 --> s6
  

Check yourself

Three to five questions on what you just heard. Every correct answer links to the page that makes it correct, so you can check the source, not just the mark.

Next: Map companies, branches and items across the link, and know what the pair carries · Back to the series · Play this as a presentation