Automation export and import

This page is the reference for moving configuration between environments. For promoting a single workflow through its own lifecycle, see Versions and deployments — that is a different mechanism and usually the right one.

Automation export and import move a bundle of objects out of one environment or tenant and into another. It is how a configuration built in a test environment is carried into production, or how a pattern that works for one institution is lifted into another tenant.

Export produces a bundle. Import consumes one. The bundle that comes out of export is directly usable as the input to import, which is what makes the round trip possible.

Available through the API only

There is no screen for export or import. Both are API operations, so this is an administrator task performed with a client rather than something a builder does in the interface. Everything on this page describes behavior the API provides; the concepts are what matter if someone else runs it for you.

Permissions

Both operations reach across the whole tenant, so a role limited to particular workspaces cannot run them. See Where a grant has to be wider than one workspace.

Operation	Your role needs
Export	Permission to view workflows, and view on every workspace for each object type the export asks for.
Import	Permission to create workflows, and create and edit on every workspace for each object type the bundle carries.

What a bundle can contain

Seven kinds of object:

Workflows	The current version of each. See Versions and deployments.
Calendars	Calendars
Frequencies	Frequencies
Properties	Properties and tags
Thresholds	Thresholds and resources
Resources	Thresholds and resources
Tags	Properties and tags

A bundle can hold any mixture of these, including just one kind. It does not have to contain workflows.

Export

Export takes a list of the objects you want and returns them in bundle form.

Only what you ask for is exported. This is the single most important thing to know about export: it does not follow references. Exporting a workflow does not pull in the calendars, frequencies, properties, thresholds or resources that workflow depends on. If you want them in the bundle, list them too.

That is a deliberate choice — it keeps a bundle to exactly what you selected — but it means an incomplete bundle is easy to produce and only shows itself on import, when the target environment turns out not to have something the workflow refers to. Build the list from what the workflow actually uses.

What export strips or omits:

Identifiers, audit timestamps and links	Removed. The bundle describes objects by name, which is what lets it land in a different environment where the internal identifiers differ.
Encrypted property values	Excluded. The property is exported and arrives with an empty value. See the caution below.
Deleted objects	Cannot be exported. Asking for one reports that it is gone rather than silently omitting it.

Encrypted property values do not travel

A property whose value is encrypted is exported without its value. This is intentional — it is what stops a secret being carried out of an environment in a file — but it means every encrypted property must be given its value again by hand in the target environment after the import. An import that appears to have succeeded can still leave a workflow unable to run for exactly this reason, so treat re-entering those values as part of the import, not as follow-up.

Import

Import takes a bundle and applies it to the current environment.

It is all or nothing

The whole bundle is applied as a single transaction. If any object in it fails for any reason, nothing is written — there is no partial import to unpick. A failed import leaves the environment exactly as it was.

A timed-out import may still have completed

A large import can outlast the service's request time limit (45 seconds by default). The request then returns 408 Request timeout, but the import keeps running and can still complete. Before you retry, check whether the objects are already there. A retry in the default mode is refused as a conflict if the first attempt finished; a retry in overwrite mode applies the bundle a second time.

Conflicts, and the overwrite decision

Import matches objects in the bundle against what already exists by name. What happens next is the one decision you have to make:

Mode	Behavior
Default (fail on conflict)	If any object in the bundle already exists, the whole import is refused as a conflict and nothing is written. Use this when the bundle is meant to be new: it will not quietly modify anything you already have. A deleted object with the same name is not a conflict; a new object is created beside it.
Overwrite	Existing objects are updated in place and new ones created. A deleted object with a matching name is restored and overwritten, so an object you deleted on purpose comes back. Use this mode when you are deliberately pushing a newer configuration over an older one, and check the bundle for names you have retired.

The result tells you which happened: everything created, or at least one thing updated.

Where imported objects land

New workflows, properties, thresholds and resources are created in the General workspace. An object that is updated or restored keeps the workspace it already had. Move new objects to their proper workspace after the import. See Workspaces.

An import does not run the commit check for sub-workflows

Importing over an existing workflow gives it a new version, and a deployment set to LATEST runs that version from its next build. A commit in the workflow editor is refused if it would leave a LATEST deployment embedding a sub-workflow that is not deployed in that environment. An import is not checked this way. Before importing a workflow with Workflow Container jobs, make sure each sub-workflow is deployed wherever the workflow runs LATEST. See Committing a version is checked too.

Names are matched exactly for every kind of object except workflows, which are matched without regard to case — so a bundle naming Nightly-Core-Export will match an existing nightly-core-export and update it rather than creating a second workflow.

An import is a clone, not a restore

Every job in an imported bundle is given a fresh identity, always — even when the bundle came out of export minutes earlier. Object identity is what other things point at, and a reused identity would make one notification member fire for two different jobs.

This has a consequence worth understanding before using overwrite mode:

Overwriting a workflow replaces all of its job identities

Importing over a workflow that already exists replaces the identity of every job in it. The workflow's history keeps the old identities and the new version carries new ones, and the two cannot be reconciled afterwards. Nothing in Continuum consumes those identities today, so the practical effect is currently nil — but it is permanent, and it is recorded by name in the audit trail rather than left to be inferred. Prefer the default mode unless you specifically intend to overwrite.

What import fixes up for you

• Names are validated against the rules for each kind of object, and an object being updated under its existing name is not re-checked. See Object naming.
• Dependency references are cleared of the source environment's internal identifiers so they resolve by name in the target. See Dependencies.
• Property values marked encrypted in the bundle are encrypted at rest on arrival, exactly as if they had been created directly in the target environment.

Troubleshooting

Symptom	Likely cause	Resolution
Import refused, reporting that one or more objects already exist	The default fail-on-conflict mode, and something in the bundle matches an existing name	Decide deliberately: remove those objects from the bundle, rename them, or re-run in overwrite mode.
Import succeeded but a workflow will not run	The bundle omitted something the workflow refers to, or an encrypted property arrived empty	Check that every calendar, frequency, property, threshold and resource the workflow uses exists in this environment, and re-enter encrypted property values.
An exported bundle is smaller than expected	Export does not follow references — only the objects named in the request are included	List the referenced objects explicitly and export again.
A property imported with no value	Its value is encrypted, and encrypted values are never exported	Set the value in this environment. It cannot be recovered from the bundle.
Export reports an object is gone	It has been deleted in the source environment	Deleted objects cannot be exported.
Import refused for permission	Your role is limited to particular workspaces, or lacks create or edit for one of the object types in the bundle	See Permissions.
Imported objects are in the General workspace	New objects are always created there	Move them to the workspace they belong in.
An object you had deleted is back	Overwrite mode restores a deleted object whose name is in the bundle	Delete it again, and remove it from the bundle before the next import.
Import returned 408, but the objects exist	The request timed out while the import carried on and completed	Expected. Check what was written before retrying.
After an import, a LATEST environment fails to build a workflow with a container job	The import is not checked for undeployed sub-workflows	Deploy the sub-workflow to that environment, or pin the workflow's deployment there.
A second workflow was expected but an existing one was updated	Workflow names match without regard to case	Choose a name that differs by more than capitalisation.