Runs and history

Every time a workflow starts, it is recorded as a run. The history is the first place to look when a workflow did not do what you expected — it shows what actually happened rather than what the diagram says should happen.

Open a workflow and select its history to see its runs, or open a single run to follow it step by step: which steps executed, in what order, which outcome each one took, and what it wrote.

What a run's status means

Running — working through the steps now. Most runs pass through this too quickly to see.

Waiting — stopped at a delay, an approval, or a wait-for-event step, and will carry on by itself. Nothing is wrong. A run can wait for days.

Paused — held and will not continue on its own.

Completed — reached the end of a path. Note that this means the run finished, not that it did everything in the diagram: a run that took a branch you did not expect, or stopped at an unconnected outcome, also completes.

Failed — a step could not finish. Open the run to see which one and what it reported.

Cancelled — stopped deliberately before it finished.

When a run fails

Open the failed run and find the step that stopped it. The most common causes are an external system not answering a Call API step, a step trying to write a value the field will not accept, and an AI step running with no credits left.

Fixing the workflow does not restart runs that already failed. Change the workflow, publish it, and the fix applies to runs that start afterwards.

When nothing runs at all

If a workflow never appears in the history, it never started. Check, in this order:

Is it published? Drafts never run.

Are automations still switched on? While they are, published workflows stay quiet for the whole account. See Getting Started.

Does the trigger match? A workflow only starts on the exact event it is set to.

Workflows and built-in behaviour

Some things WiseParts does on its own — assigning a conversation, sending an automatic reply, notifying whoever is assigned.

When one of your workflows handles one of these, WiseParts stands its own version aside so the same thing does not happen twice. If your workflow turns out not to handle it after all — a branch not taken, or a step that could not run — WiseParts does it, shortly after. You cannot end up with a conversation nobody is assigned to because a workflow had a gap in it.

This is why a workflow that closes a conversation also stops the automatic reply: closing it is a decision that no reply should be sent, and WiseParts treats it as such rather than thanking somebody you have just closed as spam.