Import & Export
Requence can package a task template — together with everything it depends on — into a portable bundle file, and import that bundle into another Requence deployment (or elsewhere within the same one). This is how you promote work between environments, for example from a development instance to production, without copying databases.
What’s in a bundle
Section titled “What’s in a bundle”Exporting a task template collects its full dependency closure:
- the task template itself (and any task templates it references via sub task nodes),
- every schema it uses,
- every service and service version its service nodes call,
- every variable it references — a secret’s value excepted, see Variables below.
The bundle is a single .requence file (plain JSON) that captures the current live state of each of those entities.
Exporting
Section titled “Exporting”From the task template list, use the Export action on the template you want to move. Requence gathers its dependency closure and downloads a <name>.bundle.requence file. Carry that file to the target deployment.
Importing
Section titled “Importing”On the target deployment, open Import from the task template list and choose the bundle file. Before importing, you’ll see a summary of what the bundle contains — the root template plus its schemas, services, and service versions.
Importing does not touch live directly. Instead it lands in a branch in the location you import into (your current User Space, Organization, Group, or Project). From there it behaves like any other branch:
- Review the diff — exactly what would be created or updated.
- Merge it into live in one step, or discard the branch to reject the import with no trace left behind.
Because it’s a normal branch, all the branching rules apply: you review the changes, resolve any conflicts, and the merge respects your access rights in the target location. Import branches are labelled “Imported from <instance>” so you can tell them apart in the branch switcher.
How entities are reused
Section titled “How entities are reused”An import is an instantiation, not a mirror — the same bundle can be imported into multiple places, any number of times. Requence remembers where each source entity was previously imported and decides, per entity, whether to create a new copy or reuse an existing one:
| Entity | What happens on import |
|---|---|
| Task template | Always imported as a fresh copy with a new identity, so it never clashes with an existing template. |
| Schema / Service / Service version | Reused if it was imported before and hasn’t changed (shows as no change in the diff). If the source changed since, the existing shared copy is updated (a visible update in the diff). If it’s new to the target, it’s created. |
Because shared dependencies are reused, importing several templates that share a schema doesn’t create duplicate schemas — they all point at the same imported one.
Variables
Section titled “Variables”Variables are the exception to the reuse table above, because they are the environment rather than the code. Importing them is create-if-absent, never update:
- a key the target already resolves — its own or an inherited one — is left completely untouched, so re-importing a development template into production never overwrites production’s values;
- a key that is missing on the target is created, with the value from the bundle;
- a secret is created without its value, since no deployment can decrypt another’s. It exists and types correctly, but starting a task fails until someone sets the value on the target. The import summary lists the secrets that need a value.
Services and credentials
Section titled “Services and credentials”A bundle carries a service’s definition but never its secrets. When a service is created on the target, Requence auto-assigns it a fresh connection key — there is nothing to enter. What you do need to do out-of-band is (re)deploy the service worker against the target deployment using that key, so the service can actually run there. The import summary lists the services that need deploying.
Snapshot and restore
Section titled “Snapshot and restore”Import and export also work within a single deployment as a lightweight snapshot/restore. Export a template to a bundle, keep the file, and re-import it later: unchanged entities produce an empty branch (nothing to do), while anything that has drifted since shows up as a reviewable update — letting you roll drift back to the snapshot.