Purpose
Moving from certified integrations to live Role Assistants is a phased adoption path — not a single deploy switch. This article describes how enterprise systems become Role Assistant-ready: systems are modeled and certified, relationships are declared, governed capabilities go live, and only then do administrators Activate for AI and end users receive role-specific assistants.
Why it matters
Teams that jump straight to chat pilots without certification and cross-system links often expose the wrong data scope or assign capabilities that operations cannot audit.
Don't: enable user-facing assistants before certification pillars and cross-system links are green for the intended role scope.
A phased flow keeps Operational Trust, Enterprise Knowledge, and Role Assistants aligned so each gate produces evidence the next role can trust.
How it works
Typical first scope pairs a generic CRM (structured customer and deal records) with a document store (contracts, policies, proposals). Names and vendors differ; the platform pattern is the same: record storage for entities, document storage for files, foreign keys linking documents to customers or deals, then governed search and capabilities on the certified corpus.
What this shows: the ordered phases from integration certification through user provisioning — who acts at each step and what artifact proves readiness.
What this is not: CLI command ladders, manifest field reference, or channel-specific setup. Those live in build and foundation configure articles.
Configure next: Operate your first Role Assistant
Phase 1 — Certify systems
Integrators model business metadata on CRM and document datasources, run the validation and test ladder, upload configuration, and pass the three certification pillars (operations, agent metadata trust, governance). Outcome: published online config with explainable scope.
Phase 2 — Foreign-key links
Architects and integrators declare cross-system relationships — for example linking a contract document to a customer or deal record. Links enable governed search, protection projection, and assistant context without duplicating vendor data.
Phase 3 — Expose and publish
Governed capabilities are exposed on datasources, integration and protection manifests are uploaded, and contracts are published. Outcome: design-time OpenAPI and MCP surfaces agents and assistants may discover.
Phase 4 — MCP live
Enterprise MCP and REST runtime paths serve certified capabilities with ABAC enforcement. External AI systems and the role-assistant runtime execute through the same mediated gateway — not embedded credentials in assistants.
Phase 5 — Admin activates role
A platform administrator Activates for AI for the target business role. Activation is an operational gate — skill promotion does not grant more permissions, and skill level does not replace certification or admin approval. Role Assistants are generated from publish and subscriptions, not hand-built in Builder.
Phase 6 — User receives assistant
An end user with a matching role receives a role-specific assistant (for example Sales Assistant). Users may set an assistant name and optional channel preference only. Users do not pick capabilities, subscriptions, or builder configuration. The platform copies role scope from compiled metadata.
Daily work starts in conversation. Work is a temporary Review Workspace for plan review, Ask, Approval, and activity — not the daily home.
Ask gathers information for the current task; it is not certified Evidence. Approval certifies a proposed business change (including Evidence certify when that is the task). Reusable proof lives in Evidence Fabrix.
Example
A regional sales organization certifies a CRM integration for customers and deals, certifies a document library for contracts, links each contract to its customer record, and passes governance with a scoped test subject. After MCP is live, the sales operations admin Activates for AI for the Sales Manager role. An account executive sees Sales Assistant and may rename it to "My Pipeline Assistant" — the runtime executes within the certified capability set for that role.
Business value
Phased adoption produces audit-friendly evidence at each step: certification logs, published contracts, protection manifests, and activation records. Sponsors can stop or narrow scope before users encounter over-broad AI access.
Limits
Channel delivery (Teams, Slack, web) requires additional admin steps documented separately. Not every deployment generates Role Assistants on day one — compilation depends on subscription filters and platform generation jobs in your environment.
Pilot scope should stay on one role and one certified system pair until operations confirms monitoring and support runbooks. Do not expand to multiple roles before evidence from the first pilot is reviewed.