Onboarding seeds a minimal set of business entities (resource types) — enough for normal enterprise work. You extend that set when the business has a real entity to govern. Prefer quality over quantity: name what people and Role Assistants work with (customer, contract, document), not every vendor object or API shape.
A customer is a business entity. A CRM company record, an ERP customer account, a document library folder, or a support account may all represent that customer in different systems. Resource types name the business meaning before AI interacts with those systems — so assistants reason about customers and contracts, not opaque object codes.
Business entities are a business perspective, not a technical catalog of schemas. Integrations still expose vendor objects; resource types translate them into the same vocabulary architects use in policies, dimensions, and Role Assistant capabilities.
Why it matters
Without a business layer, governance cannot say “Sales Managers see customers in EMEA.” Roles and dimensions only work when entities share stable, meaningful names across systems. Avoid inventing a new technical type for every field or endpoint — extend the seeded set only when accountability needs a distinct entity.
How it works
Onboarding seeds minimal business entities
→ Business extends only needed entities
→ Connected Systems map vendor objects to resource types
→ Capabilities, roles, dimensions, and protection use that vocabulary
| Layer | Question it answers |
|---|---|
| Business entity | What do people and assistants work with? |
| resourceType | Catalog key for that entity (for example customer, deal) |
| entityType | How it is stored (record, document, vector, message) |
| Capabilities | What actions may AI request on that entity? |
| Certification | Is metadata trustworthy for agents? |
Architects approve business names before integrators publish. Changing a resource type after certification triggers re-validation — capabilities and governance tests depend on stable names.
After install, the Resource type catalog is already seeded by category. You extend it in the Controller for your enterprise; you do not start from empty, and you do not enable every seed key by default.
Resource type categories
Categories help architects browse the seeded set. Treat the examples as a menu of meaningful entities — use and extend what your enterprise needs.
| Category | What it covers | Example keys |
|---|---|---|
| business | Commercial and operational entities | asset, budget, case |
| governance | Control, policy, and decision artifacts | approval, contract, decision |
| content | Documents and evidence-oriented content | document, attachment, template |
| people | Workforce and contact entities | employee, contact, department |
| collaboration | Shared work surfaces | workspace, meeting, channel |
| communication | Messages and events | email, message, conversation |
Full live inventory stays in the Resource type catalog in Miso Controller — categories here are for architecture alignment, not a dump of every key.
Trust lens vs integrator checklist
This page is the trust and architecture view. Integrators implement resource types in manifests and link resourceType in Business Entity JSON on Entity basics, types, and resource type.
Architects review:
- One primary business entity per datasource (avoid mixed semantics)
- Alignment between CRM “account” and CLM “customer” when linking systems
- Capability naming that matches business entities (
customer:*not vendor paths) - Quality over quantity — new keys only when the business needs a distinct entity
Example
A deal datasource uses resourceType: deal. Pipeline capabilities use deal.reviewPipeline. Governance certification proves a Sales Manager in Nordics sees only deals whose dimension fields match their scope — because deals and customers share consistent business entity names and foreign keys, not because each vendor object invented its own type.
Common mistakes
| Mistake | Impact |
|---|---|
| Treating the seed catalog as a technical checklist to enable wholesale | Noise, unstable governance, Role Assistants without clear entities |
| Skipping catalog registration | Validate fails or capabilities compile to opaque keys |
| Reusing one resource type for unlike business objects | Wrong governance scope |
| Linking systems without shared business identifiers | Cross-system relationships break silently |
Shared business entity names make policies portable across systems. Prefer a few clear entities Role Assistants can operate on — not a technical mirror of every integration schema.
Business value
A minimal, business-owned entity vocabulary is the foundation for trustworthy AI at enterprise scale — quality of entities over quantity of technical types.
Limits
Catalog contents and required fields evolve with platform releases — confirm current catalog behavior on the configure track before locking enterprise standards.