# Record, document, and message contracts
Enterprise Knowledge organizes external data into storage contracts — how the platform holds metadata, enforces governance, and exposes AI-ready context. The three contracts integrators model most often are records, documents, and messages.
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.
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: entityType: recordStorage, resourceType such as customer, field mappings with identifiers and dimensions.
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: entityType: documentStorage, resourceType document (or domain keys such as deal, contract), field mappings for title, classification, owner. 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 and workers that summarize threads, route escalations, or notify stewards with message-level scope and Operational Trust boundaries.
Configure: entityType: messageService, resourceType aligned to your domain (for example caseThread, channelMessage). 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 (entityType: vectorStore) 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.
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.