AI Employee Export & Import

You can package an AI Employee, its workflow and the configuration that drives it, as a reusable template, then create a fresh AI Employee from that template in the same workspace or in another workspace in your hierarchy. This is how AI Employees move between teams and environments without copying them by hand. This page covers what a template includes, how to export and import, and the version and permission rules that govern the flow.

Concepts

• Export = save as template. Snapshotting an AI Employee's workflow and configuration into a template, owned by your workspace.
• Import = create from template. Cloning a template into a brand-new AI Employee in the target workspace, with new identifiers.
• Grant. An explicit, one-directional permission that makes one workspace's template usable by a descendant workspace. Without a grant, a template is visible only inside the workspace that owns it.
• Clone. A same-workspace copy of an AI Employee. Useful for duplicating within one workspace; it does not cross workspace boundaries.

What a template includes

When you save an AI Employee as a template, Ema snapshots two things from the source workflow:

• The workflow definition — the directed acyclic graph (DAG) of typed agents that defines how the AI Employee runs, plus its interaction type (chat, dashboard, or voice — Beta), description, and icon.
• A configuration snapshot — the settings that shape behavior, captured as a point-in-time copy:

What does not travel with a template

A template carries structure and configuration, not workspace data or live state. The following are intentionally not copied:

• Knowledge base content. Knowledge Base folder names and scopes are recorded as recommendations and recreated as empty folders on import; the documents and their embeddings are not. You populate the knowledge base in the target workspace.
• Run history, sessions, evaluations, and audit events. These belong to the source AI Employee and its workspace.
• Per-resource access grants and version history. The imported AI Employee starts fresh (see Version implications and Permission implications).
• Secrets and credentials. Integration connections and API keys are workspace-scoped and are never embedded in a template.

Export: save an AI Employee as a template

From the AI Employee builder, use Save as template. You provide a name (unique within your workspace), a category, at least one "how to use" step, and optional description and benefits. Ema snapshots the current workflow DAG and configuration into a new template owned by your workspace.

Under the hood this is POST /templates with the source workflow_id. The new template's source_type is custom, and a template.created audit event is recorded. Saving a template requires the builder, builder_admin, or system_admin role.

POST /api/v1/workflow/templates
Content-Type: application/json

{
  "workflow_id": "8f3a...",
  "name": "Support Triage AI Employee",
  "category": "Support",
  "how_to_use": "1. Connect your ticketing knowledge base\n2. Publish",
  "description": "Routes inbound tickets and drafts a first reply."
}

Make a template available in another workspace

A custom template is visible only inside the workspace that created it. To use it in a different workspace, the owning workspace's System Admin grants it to a target workspace. Grants are subject to two hard rules:

• Descendant-only. The target must be a descendant of the granting workspace in the workspace hierarchy. You cannot grant to a sibling, a parent, or an unrelated workspace. A self-grant is rejected.
• System Admin only. Only a system_admin of the owning workspace can create, list, or revoke a grant.

POST /api/v1/workflow/templates/{id}/grants
Content-Type: application/json

{ "target_tenant_id": "b21c..." }

Granting records a template.grant_created audit event; revoking records template.grant_revoked. Revoking a grant stops the target workspace from creating new AI Employees from the template; it does not affect AI Employees the target already imported, because those are independent copies.

This grant is the cross-workspace/cross-environment "transport." To move an AI Employee from one environment to another, save it as a template in the source workspace, grant the template to the destination workspace, and import it there.

Import: create an AI Employee from a template

In the target workspace, the builder can pick a template — a starter, a curated template, one the workspace owns, or one granted to it — and create a new AI Employee from it, optionally renaming it and assigning it to a group. Ema creates a brand-new workflow in the target workspace, copies the DAG definition, applies the configuration snapshot, and recreates the recommended knowledge base folders as empty folders.

Under the hood this is POST /templates/{id}/create-workflow. The platform first checks that the caller's workspace is allowed to see the template (it owns it, it is a starter or curated, or it has been granted); if not, the template appears as "not found." A successful import records a workflow.created audit event in the target workspace. Importing requires the builder, builder_admin, or system_admin role.

POST /api/v1/workflow/templates/{id}/create-workflow
Content-Type: application/json

{ "name": "Support Triage (EMEA)", "group_id": "g7d2..." }

The group_id field is optional. When provided, the imported AI Employee is placed directly into that group. Omit it to import without a group assignment.

After import, finish setup in the target workspace: populate the recreated knowledge base folders, connect any integrations the workflow expects, confirm the EmaFusion™ model selection resolves to models available in the target workspace, and publish.

Clone within a workspace

To duplicate an AI Employee inside the same workspace, without going through a template, use Clone. Cloning creates a new AI Employee that copies the source's name (suffixed with "(Copy)" unless you supply a name), description, icon, category, and DAG definition, and records an ai_employee.cloned audit event. A clone refuses outright if the source belongs to a different workspace, so it is never a cross-workspace path; that is what grants are for.

Version implications

Versioning does not carry across export and import:

• The template captures one point in time. The DAG and configuration snapshot reflect the source workflow exactly when you saved the template. Editing or republishing the source afterward does not update the template, and editing the template's metadata does not change AI Employees already imported from it.
• The imported AI Employee starts a fresh version history. It does not inherit the source's published versions, drafts, or version numbers. Its first save creates its own draft version, and you publish it on its own timeline in the target workspace.
• Publish and revert are local. Publishing, promoting, and reverting versions act only on the AI Employee in its own workspace. There is no link back to the template or to the source AI Employee.

Permission implications

• Exporting, importing, and cloning are builder-tier actions — available to builder, builder_admin, and system_admin. The user and no_access roles cannot perform them.
• Granting across workspaces is restricted to system_admin of the owning workspace, and only to descendant workspaces.
• Per-resource access grants do not transfer. Any fine-grained access you configured on the source AI Employee is not copied. The imported AI Employee starts with default access in the target workspace, which you set there.
• Cross-workspace copying is structurally blocked except through grants. Clone is same-workspace only; "create from template" honors the grant check; and every copy operation writes the new resource under the caller's workspace, so a template can never pull a workflow into a workspace that was not explicitly granted access.

Reference: endpoints

What's next

• Security & Compliance — workspace isolation rules that govern cross-workspace copying.
• Governance and permissions — the roles required for each action above.
• Tenant management and SSO — the workspace hierarchy that defines which workspaces you can grant to.
• Audit log — the template, grant, and workflow events recorded by export and import.