Publish, pause and delete
Editing a workflow never changes what is running until you decide.
The three statuses
| Status | Meaning | Does it run? | Counts toward the plan limit? |
|---|---|---|---|
| Draft | Never published. | No | No |
| Active | Has a published version and is on. | Yes | Yes |
| Paused | Has a published version but is off. | No | No |
Draft and published version
Every workflow has two copies:
- The draft, which is what you see and edit in the editor.
- The published version, which is what runs when the event happens.
While you edit, the published version keeps running unchanged. If the two differ, the editor shows Unpublished changes and the button reads Publish changes.
Save the draft
Save draft (or Cmd+S / Ctrl+S on desktop) saves the name and steps. It does not validate anything or affect what is running, so you can save work in progress. The name is required: if you leave it empty you see “Give the workflow a name.”
If someone else saved the same workflow while you were editing it, Save does not overwrite their changes: you see “Someone else saved changes to this workflow while you were editing it. Reload the page to see the latest version: your changes were not saved.”
Publish
Publish (or Publish changes) does four things:
- Checks that the draft is complete. If something is missing, it does not publish and shows “To fix before publishing: N” with each problem highlighted on its step.
- Checks your permissions. The workflow will act with yours, so you cannot publish a step you could not do by hand. The editor marks the step you are missing, for example: “To publish this step you need the “Approvals” permission.“ See Which permissions it acts with below.
- Checks your plan if the workflow was not active. If you already reached the maximum of active workflows, you see “Your plan allows N active workflows. Pause one or upgrade to publish this one.”
- Copies the draft to the published version, bumps the version number and makes the workflow Active.
Publishing changes to a workflow that was already active does not use another slot.
Before publishing, the button asks you What changed?. The note is optional, up to 280 characters, and it stays in the Versions tab and on every run that uses that version.
In the same window, What will happen sums up the effect of publishing what is on screen:
- how many times the trigger happened in the last 30 days and, if you set an Only when… filter, how many of those meet it (in a very busy account the 300 most recent are checked, and it says so);
- in a scheduled workflow, when it runs next;
- how many runs are still in progress and which version they will finish with.
Publishing does not run the workflow on what already happened: it starts with the next event.
Versions
Every time you publish, the published version is replaced by a new version, and Cord numbers each publish. What matters about that numbering:
- Each run remembers its version. When it is created, the run keeps a full copy of the version published at that moment: its steps, its texts and its time limits. It runs with that copy from start to finish, even if a wait makes it last days. In Runs, the details of each run say which version it ran with and that version’s note.
- A new version only applies to new events. Queued or waiting runs carry on with the version they started with. When you retry a failed run you can use the new version: that is what Retry does.
- Every version stays in the history. The Versions tab lists each publication, newest first, with when and who published it and its note; the one that is running says Current. Restore as draft copies a version into the draft so you can review it and publish it as a new version: what runs does not change until you publish.
| You want to | Do this |
|---|---|
| Try a change without affecting what runs | Edit it in the draft, click Save draft and Test. Do not publish yet. |
| Make the change apply right away | Publish changes. It applies to events from that moment on. |
| Make a waiting run use the change | You cannot: cancel it and let the next event create one with the new version. |
| Fix the text of a run that failed | Publish the change and click Retry on the run: it runs with the published version from the step that failed. |
| Go back to a previous version | In Versions, click Restore as draft on that version and publish. |
Test before publishing
The Test button, next to Save, runs the draft with the latest real event of its trigger. It is the same run the published workflow would make, on the same engine, except that nothing leaves Cord:
- Conditions and lookups read your real data: you see which branch it would take.
- Each action is built exactly as it would go out — the subject and body your client would get, the data of a POST — and is not sent. Whatever would fail in production fails here too, for the same reason: a message that ended up empty, an internal URL, a header that can no longer be read.
- Waits count as finished: the test moves the clock forward and keeps going, so you see the whole flow in one go, with the dates of that moment. A wait-until whose condition isn’t met reaches its deadline and continues through If the time runs out.
- The test runs with your permissions, because you are the one who would publish it: a step you couldn’t publish tells you which permission is missing.
The result reads just like a run in the Runs tab: each step with what it received and what it would do. The canvas also paints the path: each step that would run gets its mark, the branch each decision would take is highlighted and what wouldn’t run is dimmed. While you view the path, the canvas can’t be edited; Back to editing, or closing the test, returns it.
If the trigger has never happened in your account yet, the test says so: there is nothing to test with. Make the event happen once (for example, send a test quote) and try again.
Testing doesn’t create a run, leaves nothing in the history and doesn’t use your sending quota.
What happens to runs in progress
Each run keeps a copy of the version published when the event happened. If you publish changes, runs already queued or waiting finish with the previous version; new ones use the new version.
That way a change never leaves a run halfway with steps that no longer exist.
Which permissions it acts with
A workflow only does what the person who published it could do by hand. Each action asks for the same permission as that action done from the app:
| Action | Publisher’s permission |
|---|---|
| Approve the internal request | Approvals |
| Void the invoice | Collections |
| Email the client, Send the client a WhatsApp and Expire the quote | Quotes |
| Create a task | Quotes, Collections or Clients |
| Send the data to a URL | Settings |
| Email the team, Slack, Teams and HubSpot | None extra |
The account owner has all of them. Cord checks the permissions again before each action, also when a run continues after a wait:
- If the person who published it is no longer on the team, no step runs on their behalf: the run fails with “The person who published this workflow is no longer on the team, so it was paused.” and the workflow is paused.
- If they no longer have the permission for a step, that step does not run, the run fails with “The person who published this workflow no longer has the permission this step needs, so it was paused.” and the workflow is paused.
To turn it back on, someone with the permission for all its steps publishes it again, and from that moment it acts with theirs. Resume is not enough, because it does not change who answers for the workflow.
When a workflow approves an internal request, the quote’s activity says so: “Approved by a workflow and sent to the client”.
Pause and resume
From the editor’s More actions menu:
- Pause turns the workflow off. It stops creating new runs and frees its slot in the plan limit. You see “Workflow paused. Runs already in progress wait until you resume it.”
- Resume turns it back on with its latest published version and you see “Workflow resumed”. If your plan has no room, you see the same limit message as when publishing. If the person who published it can no longer perform all of its steps, you see “The person who published this workflow can no longer perform all of its steps. Publish it again to turn it back on.”
Cord also pauses a workflow on its own in two cases: when the person who published it loses a permission one of its steps needs (see Which permissions it acts with) and when its last 5 runs fail or need attention (see Automatic pause). The editor and the list say why, and the notice goes away when you resume it or publish it again.
Only a workflow that has been published at least once can be paused or resumed. A draft shows “Publish the workflow before pausing or resuming it.”
Events that happen while it is paused are not recovered when you resume. Whatever was already in progress is not lost: queued or waiting runs stay on their step and continue when you resume it, and if their wait ended in the meantime, they continue as soon as you resume it. To discard one, cancel it in Runs; to discard them all at once, use Cancel waiting runs in the workflow’s menu, which tells you how many there are before it does anything. Pausing and canceling are separate decisions: pausing keeps them, canceling stops them for good.
Duplicate
Duplicate creates a new workflow named “Name (copy)” with a copy of the draft. The copy starts as a Draft, with no run history, and must be published separately. It is the quick way to have two similar workflows with different triggers.
Delete
Delete workflow removes it from your list and it stops running: queued or waiting runs are canceled. It cannot be undone from the app. Cord asks you to confirm first.
What the workflow already did is not deleted: tasks it created stay in Tasks, emails were already sent, and Slack messages and HubSpot notes stay where they are. Its run history is not deleted either: it is kept, and if you need to look at it after deleting the workflow, write to us.
If you are not sure, pause instead of deleting. A paused workflow stays in your list with its history, keeps whatever was in progress and does not count toward your plan limit.
Change log
Creating, publishing, pausing, resuming, deleting, retrying or canceling a run is recorded in Settings › Audit log, with who did it and when.
Related
- Runs and errors: what happens to each run and how to retry it.
- Limits: how many active workflows your plan allows.
- Create your first workflow: the editor, step by step.