Cloning vs Linking
When a Record Type is shared from one workspace to another, the recipient ends up with one of two kinds of access: a Linked share that follows the source as it evolves, or a Clone that is an independent copy they can edit. This article walks through which kind fits which situation, so both senders and recipients can make the right call.
At a glance
| Linked share | Clone | |
|---|---|---|
| Recipient relationship | Read-only follower | Independent owner |
| Source edits | Propagate live | Do not propagate |
| Recipient can edit fields? | No | Yes |
| Recipient can change AI instructions? | No | Yes |
| Records stay in recipient workspace? | Yes | Yes |
| Recipient can re-share? | No | Yes — it is their own type |
| Recipient can clone to escape it? | Yes | Not needed — they already own an editable copy |
| What happens when source archives the type? | Recipient loses access | Clone is unaffected |
When a Linked share fits
A Linked share is the right choice when you want consistency across workspaces. Specific cases:
- Corporate templates. A safety audit type or contractor registration form that should look the same at every site, where head office owns the schema and field changes need to roll out uniformly.
- Reporting and analytics. If you plan to roll up records from multiple workspaces (for example, monthly incident counts across all sites), keeping the field structure identical avoids reconciliation headaches.
- Active iteration. You expect to change the schema over time — adding fields, refining AI instructions, tightening validation — and want recipients to track those changes automatically.
The trade-off: recipients cannot adapt the type to their own context. If they need to customise (add a region-specific field, rename a label, change the AI agent's tone), they have to ask the source workspace to make the change, or clone.
When a Clone fits
A Clone is the right choice when the recipient needs autonomy. Specific cases:
- Local customisation. A workspace needs to add fields specific to their operation, change the AI Agent Instructions for their tone, or remove fields that do not apply.
- One-time handoff. The source wants to give a starting structure and walk away — no ongoing sync, no further changes pushed from the source side.
- Pilot or fork. A workspace is experimenting with a variation of the type. If their version works better, they can keep iterating; if not, no harm done to the original.
- Onboarding new business units. Each unit should own and evolve its own version after the initial setup.
The trade-off: the source loses the ability to push updates to the clone. If the source changes a field, the clone is unaffected. Each cloned workspace effectively forks the schema from the moment of the clone.
What happens to records in each mode
Records always stay in the workspace where they are created — this is true for both modes. A workspace using a shared Record Type (linked or cloned) builds its own record database; the source workspace does not see those records.
The difference is in the schema the records conform to:
- With a Linked share, every record in the recipient workspace conforms to the source's current schema. If the source adds a field, that field appears (empty) on existing records, and new records show the new field to whoever fills them in.
- With a Clone, every record in the recipient workspace conforms to the clone's schema at the moment it was created. If the source later adds a field, the clone is unaffected; the recipient's records and schema stay as they were.
Switching from Linked to Clone
If a recipient starts with a Linked share but later decides they need to customise the schema, they can do so without involving the source workspace. From the Record Type's page, they choose Clone to my workspace from the three-dot menu (⋯) next to + New record. This creates a new, independent Record Type owned by their workspace, populated with the current schema as the starting point. The Linked share remains in place; if they no longer need it, they can decline it from their Records Management page.
The clone is schema-only: records from the Linked share do not migrate. If the recipient had been creating records under the Linked share, those records stay tied to the source's original type, not the clone.
What recipients can and cannot do
| Action | Linked share recipient | Clone recipient |
|---|---|---|
| Use the type to create records | ✓ | ✓ |
| View their own records of that type | ✓ | ✓ |
| Edit the schema (fields, validation, AI instructions) | — | ✓ |
| Clone the type into an editable copy | ✓ | — (already editable) |
| Re-share the type with another workspace | — | ✓ — but it is their clone, not the original |
| Decline / remove the share | ✓ | — (it is their own type now) |
Source-side behaviours to be aware of
- Archiving a Linked-shared type removes it from every recipient workspace. If you have shared a type with five workspaces and then archive it, all five lose access. Records in those workspaces remain visible but the type can no longer be used to create new records. Archive only when you genuinely want the type retired everywhere.
- Archiving a type that has been Cloned does not affect the clones. Clones are independent; they live on after the source is archived.
- There is no per-recipient revoke option in this version. Once a Linked share is accepted, the only way to remove access is to archive the type at the source, which affects all recipients.