Documentation Index

Fetch the complete documentation index at: https://docs.aifabrix.ai/llms.txt

Use this file to discover all available pages before exploring further.

Cross-system relationships

  • Published on Jun 29, 2026
  • 2 minute(s) read
  • MR
  • EB
 Prev Next

Cross-system relationships connect business entities across applications — so AI understands context no single system holds alone.

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, not only technical foreign keys:

Contact → Company
Deal → Customer
Contract → Customer
Document → Project
Case → Customer
Invoice → Contract
Task → Owner

Integrators declare links in datasource JSON:

  • foreignKeys — reference another datasource or resource type
  • Field mappings — shared identifiers (customer id, contract number) that align across systems
  • Dimensions — same ABAC boundaries apply when traversing linked entities
  • Protection — scenario rules govern who may follow which links

The platform traverses relationships only through certified, exposed datasources. AI never receives raw cross-system credentials — it requests governed capabilities that respect the same trust boundaries as primary entities.

Integrator workflow

  1. Model each datasource with correct resourceType and business metadata (business metadata).
  2. Define foreign keys on child entities (deal → customer, document → project). See Configure business policies.
  3. Align identifiers — the same business key must resolve consistently (e.g. customer external id in CRM and CLM).
  4. Validate and upload — run schema validation and end-to-end tests on datasources that use relationships (Test ladder).
  5. 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 worker sees 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 verify-governance — not only primary entity reads. If a worker can follow deal → customer links, governance must prove the worker cannot see customers outside their 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.

Related articles