Enterprise Knowledge organizes external data into storage contracts — how the platform holds metadata, enforces governance, and exposes AI-ready context. Prefer business meaning first (customer, contract, message thread); storage contracts are how those meanings are held — not a technical catalog to enable wholesale.
The three contracts integrators model most often are records, documents, and messages. Systems of record remain authoritative.
Why these contracts
Vendor APIs differ: CRMs expose records, content systems expose documents, messaging APIs expose threads and channels. The platform needs a consistent business layer so Role Assistants ask for a customer overview, policy document, or escalation thread — not vendor-specific object names.
Each contract maps to a datasource entity type on the configure track — see Entity basics, types, and resource type for the literal field names and enum values.
Record storage
What: Structured business entities — customers, contacts, deals, cases, tickets.
Business use: Operational Trust dimensions, foreign-key relationships, row-level protection, governed search by attribute, Enterprise Synchronization Fabrix for shared resource types.
Configure: integrators classify the entity as record storage and name its business resource type (for example, customer), then map identifier and dimension fields — see the entity basics page above for the exact configure-track fields.
Document storage
What: Files and pages with metadata — contracts, policies, knowledge articles, deal libraries.
Business use: Catalog search, metadata filters, linkage to records (customer ↔ contract), Content Review when required metadata or links are missing — see Document approval and governance.
Configure: follow Build a document storage entity. Integrators classify the entity as document storage, name its business resource type (document, or a domain key such as deal or contract), and map title, classification, and owner fields. Multiple document libraries on one Connected System are normal — use per-entity configuration overrides for library-specific paths or list ids.
Message service
What: Threads, channels, and notifications — conversation-oriented data in Slack, Microsoft Teams, email ticketing, or similar.
Business use: Role Assistants that summarize threads, route escalations, or notify stewards with message-level scope and Operational Trust boundaries.
Configure: integrators classify the entity as a message service and name a resource type aligned to their domain (for example, a case thread or channel message). Channel delivery also uses communication Connected Systems — see Deliver assistant channels.
How contracts connect
External system (openapi | mcp | custom)
└── Business Entity manifests (one entityType each)
└── fieldMappings + resourceType
└── Capabilities + protection + Enterprise MCP
Record and document datasources often link via foreign keys so dimensions inherit (deal → customer region). Documents may attach to records without replacing record storage. Message entities may reference records or documents through governed links.
When to choose which
| If your source is… | Start with |
|---|---|
| CRM or operational database API | recordStorage |
| File library, SharePoint list, or CMS | documentStorage |
| Slack, Teams, email threads, ticketing conversations | messageService |
One vendor API may expose both files and records — choose one primary entity type per Business Entity; use foreign keys to link contracts rather than mixing semantics in one manifest.
Vector storage (optional)
Some deployments attach a vendor-specific vector or embedding interface as its own entity type for semantic retrieval. That path is an optional connector pattern — not a fourth core enterprise contract. Prefer document storage plus governed search and capabilities unless your architecture explicitly requires a dedicated vector datasource; certification and AI exposure rules still apply. See Build a vector store entity for the configure-track shape.
Governance by contract type
| Contract | Typical governance focus |
|---|---|
| Record storage | Row-level dimensions, foreign keys, CRM-style protection |
| Document storage | Classification, retention, linkage to owning records, Content Review |
| Message service | Thread participants, channel membership, escalation scope |
Architects choose contracts per Business Entity based on what the business object is, not which vendor API was easiest to import. Multiple Business Entity files in the same Connected System folder are normal when one product exposes records, libraries, and channels.
Limits
Entity type names and certification requirements evolve with platform releases — confirm the current catalog on Entity basics, types, and resource type before locking architecture reviews.
Message and document contracts may carry stricter channel and AI exposure checks than record storage — re-run governance verification when scope expands beyond the original certification.