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 tenant or in another tenant 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 tenant.
• Import = create from template. Cloning a template into a brand-new AI Employee in the target tenant, with new identifiers.
• Grant. An explicit, one-directional permission that makes one tenant's template usable by a descendant tenant. Without a grant, a template is visible only inside the tenant that owns it.
• Clone. A same-tenant copy of an AI Employee. Useful for duplicating within one tenant; it does not cross tenant 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 nodes that defines how the AI Employee runs, plus its interaction type (for example chat, form, voice, or dashboard), 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 tenant data or live state. The following are intentionally not copied:

• Knowledge base content. Data source 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 tenant.
• Run history, sessions, evaluations, and audit events. These belong to the source AI Employee and its tenant.
• 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 tenant-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 tenant), 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 tenant.

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 tenant

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

• Descendant-only. The target must be a descendant of the granting tenant in the tenant hierarchy. You cannot grant to a sibling, a parent, or an unrelated tenant. A self-grant is rejected.
• System Admin only. Only a system_admin of the owning tenant 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 tenant 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-tenant/cross-environment "transport." To move an AI Employee from one environment to another, save it as a template in the source tenant, grant the template to the destination tenant, and import it there.

Import: create an AI Employee from a template

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

Under the hood this is POST /templates/{id}/create-workflow. The platform first checks that the caller's tenant 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 tenant. 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)" }

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

Clone within a tenant

To duplicate an AI Employee inside the same tenant — 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 tenant, so it is never a cross-tenant 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 tenant.
• Publish and revert are local. Publishing, promoting, and reverting versions act only on the AI Employee in its own tenant. 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 tenants is restricted to system_admin of the owning tenant, and only to descendant tenants.
• 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 tenant, which you set there.
• Cross-tenant copying is structurally blocked except through grants. Clone is same-tenant only; "create from template" honors the grant check; and every copy operation writes the new resource under the caller's tenant, so a template can never pull a workflow into a tenant that was not explicitly granted access.

Reference: endpoints

What's next

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