> Source: https://builder.ema.ai/v2/administration/ai-employee-export-import
> Title: AI Employee Export & Import

# 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.

> [INFO]
> **Templates are the export format.** Ema does not produce a downloadable file. "Export" means saving an AI Employee as a template; "import" means creating a new AI Employee from a template. Templates live inside Ema, are tenant-scoped, and travel across tenants only through an explicit cross-tenant grant.

## 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:

Included in the snapshot

What it is

EmaFusion™ model selection

The model mode, selected model IDs, any custom model configuration, and the optimization priority.

Data protection fields

The fields flagged for protection.

Glossary terms

The custom glossary attached to the AI Employee.

Conversation and feedback settings

Conversation context, feedback on/off, positive and negative feedback reasons, and comment capture.

Welcome experience

The welcome message and welcome buttons.

Provider preference

Whether the AI Employee uses your tenant's own model providers.

Recommended data sources

The names and scopes of the knowledge base folders the source had attached, recorded as recommendations.

### 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](#version-implications) and [Permission implications](#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.

```http
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."
}
```

> [INFO]
> **Curated templates are read-only.** Templates Ema ships (`source_type: curated`) and the hidden starter templates cannot be edited or deleted. Only templates your tenant created (`custom`) can be updated, archived, or granted.

## 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.

```http
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.

```http
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

Action

Endpoint

Role

Export (save as template)

`POST /templates`

`builder` and up

List templates

`GET /templates`

`builder` and up

Update template metadata

`PUT /templates/{id}`

Owner-tenant `system_admin` or creator

Archive a template

`DELETE /templates/{id}`

Owner-tenant `system_admin` or creator

Import (create from template)

`POST /templates/{id}/create-workflow`

`builder` and up

Grant a template to a descendant tenant

`POST /templates/{id}/grants`

`system_admin`

List a template's grants

`GET /templates/{id}/grants`

`system_admin`

Revoke a grant

`DELETE /templates/{id}/grants/{tenantId}`

`system_admin`

Clone within the same tenant

`POST /ai-employees/{id}/clone`

`builder` and up

## What's next

-   [Security & Compliance](/builder/v2/administration/security-compliance) — tenant isolation rules that govern cross-tenant copying.
-   [Governance and permissions](/builder/v2/administration/governance-and-permissions) — the roles required for each action above.
-   [Tenant management and SSO](/builder/v2/administration/tenant-and-sso) — the tenant hierarchy that defines which tenants you can grant to.
-   [Audit log](/builder/v2/administration/audit-log) — the template, grant, and workflow events recorded by export and import.