Process instances
A process instance is a specific run of a template for one deal, task, or other object. While the workflow describes the procedure, the instance is its execution here and now: where the process currently is, which steps are already done, what it is waiting for, and how it ended. Instances are the control workspace: through them a manager sees that automation actually works rather than hanging halfway.
Running processes are available in the /automation/workflows section.
What an instance is
When a published process starts — manually or from automation — an instance is created, bound to a specific object. It runs through the template graph: automatic steps execute themselves, manual assignments go to people, and wait nodes hold a pause until a time or an event. Each instance has its own history and its own current step.
A single template can have many instances at the same time — one for each object the process started for.
Where to look
In the /automation/workflows section, instances are gathered on the running processes tab. From there you can open the card of a specific instance at /automation/workflows/instances/:id. The list shows the state, the linked object, and the start time; the card reveals the detailed history.
Instance statuses
An instance moves through these states:
- running — the process is executing;
- waiting — it stands at a manual assignment or a wait node (this is a normal pause, not a failure);
- completed — it reached the end;
- failed — a step did not execute and the process cannot continue;
- aborted — stopped manually with a reason.
The status is the first thing to look at when monitoring: it separates a normal pause from a stuck or broken process.
Instance card: step history
The instance card shows the linked object, the start and completion time, the current step, and the step history on a timeline. The history reads out the whole path: which nodes were passed, what executed automatically, where the process waited for a person, and how long it took.
Use the history to answer the questions: did the process actually start, which step is it on now, who must perform a manual action, and why did it complete or stop.
Due steps to run
Some process steps execute on a schedule or when a deadline arrives. Running such deferred steps ("due steps to run") gathers them and processes them in one pass, then shows a summary: how many steps were processed, how many succeeded, and how many failed.
Read the summary as the result of the run: a nonzero number of failures means that some deferred steps did not execute — they need to be reviewed in the corresponding instances.
Aborting an instance with a reason
A stuck or mistakenly started instance can be aborted. When stopping, give a clear reason: later it helps distinguish a sound management decision from a configuration error. Do not use aborting to hide a wrong template — it is better to fix the template and leave a trace in the history.
Aborting affects a specific instance and does not change the template: new runs will follow the previous graph until you edit and publish the process again.
States and limits
- an instance in the "waiting" status is a pause on an assignment or event, not a failure;
- an instance in the "failed" status means a step did not execute and the process stopped;
- an aborted instance does not resume — start a new one if needed;
- when the "due steps to run" summary has failures, some deferred steps did not pass;
- with no rights to run or abort, the corresponding actions are unavailable.
Good practices
- Regularly review running instances and their statuses.
- Distinguish "waiting" (normal) from "failed"/stuck (needs review).
- Give a clear reason when aborting.
- Review failures from the "due steps to run" summary in the specific instances.
- Fix recurring failures on the same step in the template, not with manual workarounds.
Common mistakes
Confusing "waiting" with a breakdown. A process on a manual assignment looks "stuck" while it is simply waiting for a person.
Aborting without a reason. Later it is impossible to tell whether it was a decision or an error.
Ignoring failures in the run summary. Deferred steps silently do not execute, and the procedure breaks.
Fixing a symptom with manual actions. If instances fail on the same step, the problem is in the template.
How to check the result
- the instance status matches expectations (running, waiting, completed);
- the step history shows the path taken without unexpected stops;
- the "due steps to run" summary finished without failures, or the failures were reviewed;
- aborted instances have a clear reason;
- recurring failures are resolved in the template.