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.
If a manual-task, instance, or rule card shows a technical ID instead of a name, status, or linked object, this is a display defect. Check the human title, status, assignee, and source; do not treat the raw ID as a working name or include the card in shared docs or screenshots. Send the screen to an administrator.
What an instance is
Workflow instance lifecycle — conceptual flow, not a UI screenshot or evidence.
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
Workflow instance lifecycle — conceptual flow, not a UI screenshot or evidence.
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.
The list and card load data in bounded batches: the UI requests up to 50 instances for a template and up to 100 records for each step history and timeline. An empty result means that this response has no available records; it does not necessarily prove that no runs exist. For a complete investigation, account for the response limit and open the specific instance or refresh the query.
Instance statuses
Workflow instance lifecycle — conceptual flow, not a UI screenshot or evidence.
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.
| Status | Normal or needs attention | What to do |
|---|---|---|
| Running | Normal | Nothing, as long as it fits the expected time |
| Waiting | Normal | Check who the manual task assignee is if the pause is long |
| Completed | Normal | Use it as a record for reporting |
| Failed | Needs attention | Open the card, review the step, fix the cause |
| Aborted | Needs attention | Check the reason in the history, start a new instance if needed |
Instance card: step history
Workflow instance lifecycle — conceptual flow, not a UI screenshot or evidence.
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
Workflow instance lifecycle — conceptual flow, not a UI screenshot or evidence.
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
Workflow instance lifecycle — conceptual flow, not a UI screenshot or evidence.
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
Workflow instance lifecycle — conceptual flow, not a UI screenshot or evidence.
- 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
Workflow instance lifecycle — conceptual flow, not a UI screenshot or evidence.
- 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
Workflow instance lifecycle — conceptual flow, not a UI screenshot or evidence.
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
Workflow instance lifecycle — conceptual flow, not a UI screenshot or evidence.
- 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.
Related scenarios
Workflow instance lifecycle — conceptual flow, not a UI screenshot or evidence.