Record Sharing

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.

Sharing Notifications

When a record is shared, the recipient can be notified by e-mail.

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

Architect Panel → Layout & Pages:

• E-mail Templates — the message sent

Architect Panel → Integration & Connections:

• E-mail Accounts — the account it is sent from

Architect Panel → Activity:

• Error Log — where a failure to notify is recorded

How it is configured

Three things: whether notifications are on, which e-mail template is used, and which e-mail account sends them. All three must be set — a missing template or account means the share still happens and the notification does not.

Failures are recorded, not silent

If the account cannot be found, or the recipient cannot be resolved, the failure is written to the error log and recorded against the share. So a share that was not notified is discoverable rather than merely absent.

That is worth knowing, because the visible symptom is a recipient who says they were never told.

The share still works

A failed notification does not undo the share. Access has been granted; the person simply does not know. Which is a reason to check that notifications actually work rather than assuming they do.

Write the template for somebody outside

The recipient is in a different organisation. They need to know who shared it, what it is, what they can do with it, and until when — without internal jargon and without assuming they know your product.

Say if it expires

A share with an end date should say so in the message. Otherwise the first the recipient knows about it is when access stops, usually in the middle of something.

Do not put the content in the e-mail

The message should say a record has been shared and how to reach it, not reproduce it. E-mail leaves your control entirely, and the whole point of a share is that access is governed and revocable.

Consider whether to notify at all

For a working relationship where shares are routine and expected, notification per share becomes noise people filter. For occasional shares it is essential. Decide per situation rather than switching it on and forgetting.

Test it before relying on it

Share something with a test account in another tenant and confirm the message arrives, reads well, and the link works. This is a three-part configuration and all three parts have to be right.

Worked example

A platform notifies on share with a template naming the sender, the record and its expiry date, sent from a monitored address. Testing before launch found the configured e-mail account had been deleted, so shares would have been silently unnotified.

Recommendations

• Set all three — on, template, account.
• Test with a real share to another tenant.
• Say who shared it and until when.
• Never put the record content in the message.