Copy a workflow

Task walkthrough: Create a workflow. This page is the full reference for what a copy carries across.

Copy Workflow creates a new workflow from an existing one. It is the usual way to start a second workflow that is structurally similar to one you already trust — a statement run for a second region, or a nightly core export for a second institution — without rebuilding it.

The copy is a new workflow from the moment it is created. It is not linked to its source: editing either one afterwards has no effect on the other.

Making a copy

Copy Workflow is on the toolbar of the workflow editor. It is unavailable in two cases, and the tooltip tells you which one applies:

The button is disabled because	What to do
The workflow has never been saved	Save it first. There is nothing to copy until it exists.
Your role does not permit it	The tooltip names the permission you are missing. See Roles and permissions.

Two things about a copy are easy to get wrong:

• The copy is made from the last committed version, not from what is on your screen. Edits that are only in your browser's auto-saved draft are not carried across. Commit them first if you want them in the copy.
• The copy is always created in the General workspace, whatever workspace the source belongs to. Your role needs permission to create workflows in General, or the copy is refused. To put the copy somewhere else, change its Workspace in the copy's Workflow Settings panel and commit. See Workspaces.

The dialog asks for a name and offers three options.

Workflow name

The name defaults to the source name with - Copy appended. A long source name is truncated so the result still fits the limit, rather than offering you a default the save would reject.

Workflow names follow the legacy Master Schedule rules, which are not the same as the rules for most other objects in Continuum — see Object naming:

Rule	Value
Maximum length	40 characters
Minimum length	1 character
Rejected characters	' | ; % & < > ( ) [ ] { } , = ! \ "

Hyphens, slashes, spaces and accented letters are all accepted. The dialog checks the name as you type and applies the same rules the save applies, so a name the dialog accepts is one the save will accept.

note

Save stays unavailable while the name is empty or fails a rule. A name already in use is only detected when you save, and reports a name conflict.

Copy jobs

On by default. Every job in the source workflow is copied along with it.

Each copied job is a new job, not a second reference to the original. This matters more than it sounds: a job's identity is what other objects point at, so if a copy reused it, a notification group naming that job would fire for the original and the copy. Copied jobs are given fresh identities so that cannot happen.

Clear this option to copy the workflow's settings and structure only — build settings, frequencies, calendars — and add jobs yourself afterwards. The workspace is not carried across either way; see Making a copy.

Navigate to this workflow after copy

On by default. Opens the new workflow in the editor as soon as it is created. Clear it to stay on the source workflow; the copy is created either way and is available from the workflow list.

Copy auto/copy privileges

This option has no effect yet

The control appears on the dialog and can be selected, but nothing is carried across by it — the copy is created exactly as though it were left clear. It is off by default, so an ordinary copy is unaffected. Set access on the copy through its workspace and roles instead; see Roles and permissions.

What happens to dependencies

Dependencies are the one part of a copy that needs thinking about, because a dependency names a predecessor and a copy changes which workflow that name resolves in.

The dependency points at	In the copy
A job in the same workflow	Rewritten to point at the copy's own job. The copy is self-contained: its internal sequencing is preserved and does not reach back into the source workflow.
A job in a different workflow	Left as it is. That workflow is untouched by the copy, so the dependency keeps pointing at it — and the copy will wait on it exactly as the source does.

The second row is the one to check after copying. If you are copying a workflow in order to run an independent second stream, a cross-workflow dependency means both streams still wait on the same external predecessor, which may or may not be what you want.

After the copy

The copy is created as a new, undeployed workflow. Nothing about the source's deployment carries across — deploy the copy deliberately when it is ready. See Versions and deployments.

Review at least these before deploying:

• Workspace. The copy is in General. Move it if it belongs elsewhere.
• Build settings. The copy inherits daysInAdvanceToBuild, daysToBuild, buildTime and the rest. Two workflows building the same dates is usually intended; two workflows both configured to build unattended may not be. See Scheduling and the run.
• Cross-workflow dependencies, per the table above.
• Properties and tags. Property references are carried by name, so the copy resolves them the same way the source does — including any that are environment-specific.

Troubleshooting

Symptom	Likely cause	Resolution
Copy Workflow is greyed out	The workflow has unsaved changes and has never been saved, or your role does not allow it	Read the tooltip: it distinguishes the two. Save first, or ask for the permission it names.
Save stays unavailable in the dialog	The name is empty, longer than 40 characters, or contains a rejected character	The field shows which rule failed. Shorten the name or remove the character.
Saving reports a name conflict	A workflow already uses that name	Choose another. Names are matched without regard to case, so changing only capitalisation does not resolve it.
The copy is in the General workspace, not the source's	A copy is always created in General	Change the copy's Workspace in Workflow Settings and commit.
The copy is missing changes you had just made	The copy is made from the last committed version; your browser draft is not included	Commit the source first, then copy it again.
The copy is refused for permission although Copy Workflow was available	Your role can create workflows, but not in the General workspace	Ask for permission to create workflows in General.
The copy waits on a job that has nothing to do with it	The source had a cross-workflow dependency, which is deliberately preserved	Remove or repoint that dependency on the copy.
Selecting Copy auto/copy privileges carried no access across	That control has no effect yet	Expected. Grant access on the copy through its workspace and roles.