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.
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
- Model each datasource with correct
resourceTypeand business metadata (business metadata). - Define foreign keys on child entities (deal → customer, document → project). See Configure business policies.
- Align identifiers — the same business key must resolve consistently (e.g. customer external id in CRM and CLM).
- Validate and upload — run schema validation and end-to-end tests on datasources that use relationships (Test ladder).
- Certify governance — governance verification proves subject-scoped visibility across linked context (Test ladder and protection and Protection manifests and upload).
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.