Entity basics, types, and resource type

Set entityType and root resourceType on each Business Entity manifest so sync, storage, RBAC, and AI exposure follow the correct contract.

Prerequisites

Connected System type chosen (Basics and kind)
One JSON file per Business Entity under integration/<systemKey>/
Builder CLI authenticated — aifabrix auth status green

Where it lives

<datasourceKey>.json → top-level entityType, resourceType, key, displayName, systemKey.

Manifest sections: datasource.basics, datasource.entityType, datasource.resourceType. Both identity fields sit at the datasource root — never nest resourceType under fieldMappings.

Builder MCP


Manifest sections	`datasource.basics`, `datasource.entityType`, `datasource.resourceType`
UI tab	Overview / Technical readiness
Help topics	`section`, `goldenExamples`, `goldenExample`
Repair hooks	`fieldMappings`, metadata schema alignment

Entity type recipes: Business Entities guides.

How to set

Create or open the entity file — scaffold the Connected System folder first:

aifabrix create <systemKey> --type external
aifabrix repair <systemKey> --dry-run

Classify each Business Entity — what it primarily stores or represents.
Set entityType per schema enum:

entityType	Use when	Enterprise Knowledge role
recordStorage	CRM-style entities (customers, deals, cases)	Structured records with metadata
documentStorage	Files with metadata, no vector index	Document catalog and search
vectorStore	Embeddings and semantic search	Vector-backed retrieval
static	Reference data with infrequent change	Stable lookup tables
service	Callable capability without record storage	Governed operations

Align fieldMappings and sync — record types use business entities; document types emphasize file metadata.
List catalog keys — reuse standard tokens when possible:

aifabrix resource-type list
aifabrix resource-type get --key customer

Create missing catalog keys before first upload:

aifabrix resource-type create --key customer --display-name "Customer" --category business

Set resourceType at the datasource root and validate:

aifabrix datasource validate <datasourceKey>
aifabrix validate <systemKey>

Continue in entity guides — record storage, document storage, or other guides overview for schema bands beyond identity.

Defaults and examples

Element	Purpose	Example
`entityType`	Storage and sync model	`recordStorage`, `documentStorage`
`resourceType`	Business catalog token	`customer`, `document`, `deal`
`key`	Entity identifier	`example-crm-customers`
`systemKey`	Parent Connected System	Must match system JSON

Example identity fragment:

{
  "key": "example-crm-customers",
  "displayName": "Customers",
  "systemKey": "example-crm",
  "entityType": "recordStorage",
  "resourceType": "customer",
  "primaryKey": ["externalId"]
}

Illustrative classification goals:

CRM companies → recordStorage + customer
SharePoint library → documentStorage + document
reference lookup table → static + catalog key matching business vocabulary

Validate

aifabrix repair <systemKey> --dry-run
aifabrix datasource validate <datasourceKey>
aifabrix validate <systemKey>

Wrong entityType often surfaces as sync or CIP compile errors — not auth failures. Re-run validate after changing resourceType; protection and subscription filters reference catalog tokens at runtime.

Common mistakes

Mistake	Fix
`resourceType` under fieldMappings	Move to root next to `entityType`
Invented catalog token	Create with `resource-type create` first
Document entity with recordStorage	Switch `entityType` to match storage model
Skipping repair after identity edits	`repair` syncs metadata schema hints

Limits

entityType drives sync bands, CIP templates, and UI tabs — changing it after publish may require re-modeling field mappings and protection. resourceType must exist in the platform catalog before upload; this page shows shape, not every catalog category. Complex multi-entity vendors still use one Business Entity file per governed resource — do not merge unrelated resources into a single JSON file.

Documentation Index