Docs
Workflows

How to publish, switch on and read a run

Publish makes a workflow live, its switch decides whether it runs, and the Runs tab shows what it did.

A workflow runs only when two separate controls agree, and mixing them up is the commonest reason one seems not to work. Publish, on the workflow's canvas, makes a version live. The switch on its row in Brain › Workflows decides whether that live version runs.

The Runs tab on each workflow then shows every recent run, step by step. New to workflows? Start at What are workflows?.

What does publishing do?

Publish saves what is on the canvas, checks every step, and makes that version the live one. A Workflow published. message confirms it, and the status at the top of the page reads published.

You need Publish workflows for this, and Build and edit workflows to reach the canvas controls. Admins have both by default. See How to set who can do what.

What happens when you change a published workflow?

Saving any change returns it to draft, and a draft does not run. That includes moving a step or tidying the layout, because Save always saves the whole canvas.

Finish every change with Publish, which saves and makes it live in one go. The workflow runs again the moment Publish succeeds. Renaming a workflow from its title leaves its status as it was.

If Publish refuses, your changes are still saved as a draft. Fix what it names and publish again to get the workflow running.

Does publishing switch it on?

No. Publishing and the switch are independent, and a new workflow starts switched off.

Turn it on with the switch on its row in Brain › Workflows. For a workflow to do anything it has to read published and be switched on.

Switching it off stops it without touching its steps, so it is the safe way to pause one.

Why did publishing refuse?

Because a step is incomplete, and the message lists every problem in one place. It stays on screen until you close it, so you can read all of it.

Most problems also mark their step on the canvas with a red outline and a short message. The usual causes:

  • The trigger. "A workflow needs exactly one trigger." appears when there is none or more than one. It shows only in the publish message.
  • Nothing connected. A trigger with no line to a first step, or a step that is not joined back to the trigger. The second shows only in the publish message, so look for a step sitting on its own.
  • A condition. Compare any field with no rules, or a rule with no comparison chosen. See How to add a yes/no decision.
  • A line out of a condition that does not leave from the Yes or No dot.
  • Create task with no title or no department.
  • Update a field with nothing chosen to set the field to.
  • A create step missing a field the record needs, marked with an asterisk in its options.
  • Notify someone with no message, or nobody chosen to tell.

Fix the flagged steps and publish again. A workflow built in an older version of the editor asks you to open it, rebuild the steps and save before publishing.

How do you read a run?

Open the workflow and choose the Runs tab. It lists the 50 most recent runs, newest first, each with its status, how long ago it ran and how long it took.

Expand one and it reads as a story down a timeline. The trigger comes first, naming the record that set it off. Then each step has a card saying what it was set up to do and what it actually did.

A condition says whether it matched and which path it took. A Create task card names the task it created, who it was assigned to and when it is due, with an Open the task link. A Notify someone card says how many people it told and how many devices buzzed.

A step that went wrong shows its reason in red. A step the run never reached has a hollow dot and says The run never reached this step., which is how you see where a branch stopped.

The last line names whose access the run used, for example Carried out with Priya Raman's access. That is the workflow's owner.

What do the run states mean?

Each run shows one of five states.

  • running: it is working through its steps now.
  • completed: every step it reached worked.
  • partially completed, in amber: some steps worked and at least one did not. Expand it to see which.
  • failed: nothing it tried worked, or the run stopped early. The reason is in the expanded run, for example when the triggering record was deleted before the run reached it.
  • cancelled: Tideswell skipped the run to stop a workflow repeating itself, and the run says why. See How to create tasks and records from a workflow.

Why has it not run at all?

Work down these.

  1. Is it published, and is it switched on? A save since the last publish puts it back to draft.
  2. Has enough time passed? Tideswell checks for changes every five minutes or so.
  3. Did the record change in a way the trigger watches? A trigger with Only when these change ticked ignores every other edit. See How to choose a trigger.
  4. Is the Workflow engine switched on? It is under Background jobs on Brain › Automations: press Show all to find it. Turning it off stops every workflow.
  5. For a workflow that starts from a Shopify order, product or customer: is the Shopify change watcher switched on? It sits in the same list. See How to turn an automation on, off, or run it now.

The empty Runs tab says the same: publish it, turn it on, then change a record it watches. Why an automation or workflow did not run covers this alongside the automation cases.

How do you retire one?

Press Archive on its row in Brain › Workflows and confirm. An archived workflow stops running and leaves the list for good.

Make sure before you archive, because it cannot be brought back. If you are unsure, switch it off instead and watch for a week.

On this page