The three reference modes
The three reference modes
Spoke templates lean on master data they do not contain. Cybersecurity wants an Owner who is a Person. Vendor Management wants Spend tied to a Cost Center. In the hub-and-spoke architecture, those types live in the Core schema, not in the spoke you are deploying.
So when you deploy a spoke, every one of those external references needs an answer: what should this point at in your site? The deployment wizard asks you to resolve each one, and there are exactly three ways to do it.
Mode 1: link to a shared schema
The wizard wires the reference to the matching object type in a schema you already have. If Core is installed, this is the recommended choice, and the wizard treats it as the default.
What you get:
- A real cross-schema object reference. The spoke's Owner field offers your actual Core Person objects.
- One copy of the truth. Every schema that links to Core reads and updates the same records.
- No cleanup later. The spoke arrives already integrated.
Linking depends on the target schema allowing other schemas to reference it. You do not need to prepare anything: LaunchPad enables that setting on the link target automatically and records that it did. The details are on the cross-schema sharing page.
Mode 2: create here
No Core schema yet? The wizard can create the referenced type inside the schema you are deploying, built from the bundled Core definition. Your spoke still gets a real Person type with the right shape, it just lives locally rather than in a hub.
This is the standalone fallback, and it is deliberately conservative:
- One level only. The wizard creates the type you referenced, and stops. It does not chain onward into everything that type references in Core.
- Scalar attributes only. The local copy gets the Core type's text, select, date, and number attributes. Its outward object references are not carried across, because their targets will not exist in your schema.
- With one useful exception. When several types created in the same deployment reference each other, those references are wired. Deploy Cybersecurity standalone, for example, and both Person and Team are created locally, so Person's Team reference is created as a real object reference between the two local copies.
Create here is what lets Foundation starters run on a fresh site: Basic CMDB on a site with no Core relies on it to provide Person and Location for its Managed By and Located In references.
The trade-off is the one the hub-and-spoke architecture exists to avoid: if three schemas each create Person locally, you have three people lists. That is fine for getting started and increasingly costly at scale, so prefer linking as soon as a hub exists.
Mode 3: keep as text
The reference becomes a plain text attribute. "Owner" holds the string "Sarah Chen" rather than a link to an object.
Choose this when:
- Master data lives somewhere else entirely and you only need a label, not a relationship.
- You want zero coupling for this attribute, now and later.
Text is honest about what it is: no integrity, no traversal, no AQL across the relationship. Converting a text attribute into a real reference later is manual work, covered in Connecting models together. Use it sparingly and deliberately.
The three modes side by side
| Link to a shared schema | Create here | Keep as text | |
|---|---|---|---|
| What you get | Reference to an existing shared object type | New local type from the bundled Core definition | Text attribute |
| Shared master data | Yes | No, local copy | No |
| Works without Core | No | Yes | Yes |
| Depth | Full Core type, in place | One level, scalar attributes, intra-deploy references wired | None |
| Best when | Core (or another hub) is installed | Standalone first deployment | You only need a label |
You make the choice per external reference, so mixed resolutions are possible: link the references your hub can serve, create or text the rest.
The same choice in the Expand flow
Deployment is not the only place you meet this decision. When you run Expand against an installed service model, the same question comes up for any external reference the template brings with it, and the flow includes an equivalent resolution step: link the reference to a schema that already has the target type, or create it locally as part of the expansion.
The reasoning is identical in both places. If a hub is present, link to it; if not, create what you need and consolidate later.
Where to next
- Cross-schema sharing: the setting that makes Link work, and what happens when it cannot be enabled.
- Hub-and-spoke architecture: why linking to Core is the recommended default.
- Install a service model: the deployment walkthrough these choices sit inside.