Sharing a Record
Record sharing lets one tenant grant another access to a specific record — a deliberate, narrow exception to isolation.
Where to find it
Architect Panel → Configuration:
- Multitenancy — the tenants themselves
- Custom Tenant Information Fields — your own fields on a tenant
- Instance Configuration Fields — settings held per tenant
What a share records
The sending tenant and the person who sent it, the receiving tenant and the person receiving it, which table and which row, whether it is read-only, an optional expiry, and whether it has been revoked.
Both sides are identified by login method, unique identifier and domain — so shares work between federated users as well as inbuilt accounts.
It is per record, not per table
Which is the point. This is not a way to open a datastore to another tenant; it is a way to hand over one specific thing — a document, a case, an order — that genuinely needs to cross the boundary.
The tenant must allow it
Sharing is a flag on the tenant, so it can be off entirely. For customers whose contracts or regulators forbid data leaving their tenant, that is the correct setting and it should be set deliberately rather than left at whatever the default was.
Read-only by default in practice
A share can be read-only or not. Read-only should be the normal case: the receiving tenant needs to see the record, not to change data belonging to somebody else.
Writable shares mean two organisations editing one record, which needs a reason and an agreement about who owns it.
Always set an expiry
The single most useful habit here. A share without one lasts until somebody remembers to revoke it, and nobody remembers.
Shares are usually created for a reason with a natural end — a project, a case, a transaction. Put that date in when you create it.
Revocation keeps the record
Revoking marks the share as revoked rather than deleting it, so the history of who had access to what, and when it ended, survives. That is what you need if anybody ever asks.
Duplicates are detected
Sharing the same record with the same person again finds the existing live share rather than creating a second one. So the list stays meaningful rather than accumulating repeats.
Review active shares
Periodically, per tenant. Every live share is data crossing an isolation boundary, and the list should be short and each entry explicable.
Worked example
Two customers collaborating on a project share individual case records read-only, each with an expiry matching the project end date. A quarterly review of live shares found three from a completed project, which were revoked — leaving the record of who had had access.
Recommendations
- Always set an expiry.
- Read-only unless there is a reason.
- Turn sharing off for tenants whose contract forbids it.
- Review live shares per tenant, quarterly.