Cross-system relationships connect business entities across applications — so AI understands context no single system holds alone. Existing applications remain the systems of record; relationships assemble business context, they do not create a second master of the data.
When assistants traverse links, Operational Trust still applies. Relevant is not the same as permitted.
Why it matters
A customer in CRM links to contracts in a CLM tool, documents in a file store, cases in support, and tasks in project systems. Traditional integration moves data between silos. Enterprise Knowledge connects that data into one governed business context.
Without relationships, Role Assistants see isolated records. With them, a Sales Assistant can review a customer with deals, contracts, open cases, and related documents — always within role, dimension, and protection rules.
Without this shared map, each AI solution has to reconstruct the same business navigation through orchestration, workflows, prompts, tool calls, or model reasoning. With it, Role Assistants start from reusable business context instead of rediscovering how the business fits together for every task — see Enterprise Knowledge overview.
How it works
Relationships express business links. Integrators declare them on the Build track (foreign keys, shared identifiers, dimensions, protection). This page stays at business meaning:
Contact → Company
Deal → Customer
Contract → Customer
Document → Project
Case → Customer
Invoice → Contract
Task → Owner
Configure detail: Entity basics and foreign keys and related Build pages. Foreign keys improve trust and discovery; they do not by themselves make records search return one joined row shape. When the business needs a predefined picture, publish a viewpoint.
The platform traverses relationships only through certified, exposed datasources. AI never receives raw cross-system credentials — it requests governed capabilities under Operational Trust.
Integrator workflow
Integrators model each datasource's business entity and foreign keys, align identifiers so the same business key resolves consistently across systems, then validate and certify before a relationship carries governed visibility. See Configure business policies and Test ladder and protection for the Build-track steps.
Example
A Sales Assistant reviewing a customer combines:
- CRM deals and contacts (customer datasource)
- Signed contracts (CLM datasource linked by customer id)
- Open support cases (case datasource linked by customer)
- Related documents (file store linked by project or customer)
The employee does not manually gather links from four UIs. Operational Trust ensures the Role Assistant and user see only what their role and dimensions allow across all linked sources.
Common mistakes
| Mistake | Impact | Fix |
|---|---|---|
| Technical keys only, no business resource type | AI cannot name what it linked | Set resourceType on both sides |
| Mismatched identifier fields | Links break silently in search | Align field mappings and foreignKeys |
| Relationships without dimensions | Over-broad cross-system visibility | Apply dimensions before certification |
| Linking to non-exposed datasources | Capabilities cannot traverse | Set exposed and upload |
Certification and relationships
Relationship traversal is included in governance certification — not only primary entity reads. If a Role Assistant can follow deal → customer links, governance must prove it cannot see customers outside the user's dimensions via that path.
Document relationship design in architecture reviews alongside datasource manifests. Architects use Adopt — operating model for steady-state ownership after integrators publish links.
Business value
Cross-system relationships enable holistic customer, project, and contract views — the difference between searching silos and understanding the business.