T2T Admin

Connects one BigLedger tenant to another — two independent subscriptions, each with its own database — so that one can see and reference a controlled slice of the other: a host owns the shared data, a guest consumes it, and the connection starts with an invitation the guest accepts. Across it you can map companies and branches, share items (the host permits, the guest pairs) and run external teams. It is not multi-company accounting, and mapping the two sides moves no document between them — nothing in sales, purchasing, stock or journals reads a T2T mapping; almost every write touches two databases, and a connection, once made, can change status but never be deleted.

Overview

T2T (“tenant to tenant”) connects one BigLedger tenant to another — two independent subscriptions, each with its own database — so that one can see and reference a controlled slice of the other. One tenant is the host (it owns the data being shared) and the other is the guest (it consumes the shared data). The connection is created by an invitation that the guest has to accept.

Once the two are connected, four things can be linked across the connection: companies and branches (business mapping), inventory/financial items (item-to-tenant permission, then item-to-item mapping), teams and roles, and an audit trail of everything that was done to the connection.

T2T is not multi-company accounting. Several companies inside one tenant are handled by the Organization applet; T2T is for a relationship between two organisations that each run their own BigLedger tenant — typically a distributor and a dealer, or a principal and a franchisee.

Where it fits

Apart from the two consumers above, nothing else in the platform reads a T2T mapping — no sales, purchase, stock or journal process consults a business mapping or an item link. Mapping the two sides does not, by itself, move a document between them.

Screens and menus

The wiki has no captures of this applet yet. What can be stated is the set of functional areas the applet is built on:

The T2T Item Mapping tab inside Doc Item Maintenance is the one T2T surface whose source is readable. It has three sub-tabs — Host Tenant, Guest Tenant Item Mapping and Guest Tenant Permission Listing — and it loads the list of connections before anything else, which is why an item’s T2T tab is empty until a connection exists.

Configuration

Before you can use it

• A second tenant that already exists. Invitations are addressed by tenant code, and the platform looks the code up before doing anything. Inviting your own tenant code is refused: the code must differ from your own.
• The other tenant must be fully provisioned. T2T writes into both tenants in one call; if the platform cannot reach the other tenant the call fails, and only BigLedger can fix that.
• Companies and branches on both sides. A mapping names a company and branch on each side, and the pair is not checked against either tenant’s records when the mapping is saved, so choose carefully.
• Items in both tenants, before item mapping can pair them.

Applet settings

None are documented. No backend behaviour depends on a T2T applet setting, so whatever the applet’s own settings screens offer changes only what those screens show.

Feature visibility / permissions

T2T has its own permission family, and it is unusually complete: every resource carries OWNER, ADMIN, MEMBER, CREATE, UPDATE, DELETE and READ codes.

Every T2T action applies the same rule: the caller passes if they are the tenant owner or admin or hold any one of that action’s required permission codes. A read the caller is not entitled to does not error — it returns the record with its status replaced by PERMISSION_DENIED and every other field stripped. Expect blank rows rather than an error message.

Fields

The applet’s own forms are not documented; what follows is what each T2T record holds.

Tenant link — the other tenant’s code (must differ from your own and must exist); whether this side is the host or the guest; a status of INVITED, CONNECTED, REJECTED or DISCONNECTED (the only four states); a free-text name and description, written identically on both sides at invitation time; and whether the host still permits the guest to reconnect (set when the invitation is created).

Business mapping — your company and branch; your customer/supplier record for the other party (the header and the specific address/contact line); and the tenant on the other side. The server also writes a partial copy into the other tenant — see Lifecycle. Setting a mapping INACTIVE stops nothing: the status is not enforced, and an inactive mapping is accepted and listed like an active one. To end a mapping, delete it from the side that created it.

Item permission — the host’s item being opened up and the guest tenant allowed to map to it. To stop sharing an item, delete its permission.

Item mapping — the item in this tenant, the item in the other tenant, the other tenant, and whether the other side is the HOST or the GUEST, which decides which side may write the pair.

Audit trail event — the tenant the event concerns; one of thirteen actions (for example CREATE_NEW_GUEST_TENANT, INVITATION_ACCEPTED, CREATED_NEW_MAPPING); an event code (CREATE, MAIN_DETAILS, DELETE, INVITE, MAPPING); which side logged it; and who and when.

Lifecycle and effects

T2T writes no journal and moves no stock. It maintains link tables, and its defining property is that almost every write touches two databases.

Connecting the two sides

1. Invite. The host sends the invitation by the guest’s tenant code. The server writes one connection record on the host’s side (marked guest) and one on the guest’s side (marked host), both INVITED, both with host approval set.
2. Answer. The guest answers with ACCEPT, REJECT, DISCONNECT or CONNECT. Both records move to CONNECTED, REJECTED or DISCONNECTED together. CONNECT (reconnecting after a disconnect) is refused unless the host still approves it.
3. Audit. Each step writes an audit trail event.

The two sides are written one after the other, not as one transaction. If the second write fails, the first is undone and the call fails. If that undo itself fails, the two sides disagree about the connection, and nothing reconciles them automatically.

A connection cannot be deleted. A connection record, including a REJECTED one, is permanent; it can only change status.

Mapping companies and branches

The server writes a copy of the mapping into the other tenant, but the copy is partial: it carries only the other tenant’s own company and branch (what you entered as the other company and branch) and your customer/supplier record as their other party. It holds neither your company and branch nor the record they keep for you. So the other side’s paired view shows a blank against those branches, its mapped-only view leaves the pair out, and a delete attempted from that side does not go through. Maintain a mapping from the side that created it. Update and delete from that side locate the copy by the entity line or the branch.

Two views of the mappings exist, and the difference matters: one lists every company/branch of every connected tenant, with a blank where no mapping exists; the other lists only the pairs that are actually mapped. Both read the other tenant’s companies and branches live, per connected tenant, so they slow down as connections grow.

Sharing items

Item sharing is deliberately two-step and host-controlled:

1. The host grants a permission: “guest tenant X may map to my item Y”. This is the only T2T write that fires a webhook — T2T_ITEM_TO_TENANT_LINKING_ADDED on create and T2T_ITEM_TO_TENANT_LINKING_UPDATED on update.
2. The guest creates the item-to-item pair. The server refuses if no permission row exists (the host has not allowed linking to that item) and refuses if the guest tries to describe the other side as a guest rather than a host. The server composes the row for the host’s database itself and writes both.

An item can only be in one pair per connection in each direction — a second attempt is refused because the host’s item is already linked with another item of the guest tenant (or the guest-side equivalent).

External teams

An external team is an ordinary team flagged as T2T and tied to the other tenant. Creating one also makes the creating user its OWNER with the title T2T OWNER; because both records live on the same side, this write is all-or-nothing, unlike the connection and mapping writes. Adding and removing members writes ordinary team-membership rows.

Related applets

• Doc Item Maintenance — hosts the T2T Item Mapping tab, the only shipped screen that reads and writes T2T item links.
• Organization — supplies the companies, branches and customer/supplier entities that a business mapping pairs up.
• Tenant Admin — administers a single tenant; T2T administers the relationship between a connected pair.
• Employee — the users who end up in an external team.

Troubleshooting

Related documentation

• Doc Item Maintenance applet
• Organization applet
• Core module