Process instances
Instances is where you follow the executions that are running and the history of processes already finished.
Who sees an instance, and who can cancel it
Manager, Admin and Super Admin see every instance in the tenant. A User sees the instances they take part in: the ones they started, the ones they have a task in now, and the ones they had a task in before.
It is the same rule the Tasks screen applies, and the two screens agreeing is deliberate: whoever sees the instance sees its tasks.
An instance you take no part in answers as if it did not exist — deliberately: saying "access denied" would already confirm that it does.
Cancelling, suspending, reactivating and unblocking a failed automated step are Manager or Admin actions. If you do not see those buttons, your role does not carry them — the screen is not broken.
What is an instance?
An instance is a single execution of a process or case. When someone starts the "Purchase Approval" process, an instance is created — each request is a separate, independent instance.
Starting a process
- Open Instances in the sidebar and click New instance
or open Process Catalog to see the available processes and start from there - Pick the process or case you want
- Fill in the start form (the process's initial variables)
- Click Start
The instance is created and the first tasks go automatically to the people responsible for them.
Run as a test
Whoever administers the tenant sees a Run as a test switch on the start dialog. It exists because publishing a version without running an instance first is doing a poor job — and until now the platform could not say afterwards that anyone had done it.
The flow runs for real. Webhooks fire, robots run, e-mail goes out, agents spend tokens. That is deliberate: a test that skips the webhook does not test the webhook. Whoever runs the test owns where it lands.
What changes:
- the instance is born marked, and the mark is set at start — no screen, button or endpoint adds or removes it later, which is what stops "was this a test?" from being an argument;
- it and its tasks are only visible to whoever models (Admin or Super Admin). Hiding the instance while its task still lands in an operator's inbox would be worse than hiding nothing;
- everything it starts is born marked: a sub-process of a process, a sub-case of a case, a process called by a case and a case called by a process. An embedded sub-process does not count — it runs inside the same instance, which is already marked;
- it is kept out of the process load in the Monitor and out of self-learning, and appears there as a separate count: "N test run(s), kept out of these numbers";
- it stays in the history and in the audit export, marked as a test. It really happened, and it fired what it fires.
The mark lasts 90 days
After that the mark expires and the run becomes an ordinary line again: it reappears in the Monitor and, if it somehow still holds an open task, that task starts reaching the operator's inbox. The register of test runs cannot grow forever — the Dashboard counters read it on every load — and a test run still waiting on a person three months later is not a test in progress: it is abandoned work, and the honest place for it is the list where abandoned work is visible. The Super Admin adjusts the window in the server configuration (TEST_INSTANCE_RETENTION_DAYS). Nothing is removed from the history: what expires is the hiding.
Can AI assistants start one for you?
Only if the process allows it. On the process's Configuration tab, the AI assistants (MCP) field decides what an assistant connected to the platform may do with it:
- Nothing — the default. The process accepts neither a start nor a task completion from an assistant.
- Start and read — the assistant starts instances and reads your task inbox, but never completes anything.
- Start and complete — the assistant also completes tasks, and only after showing you exactly what it will write and where the instance will go; you confirm before it counts.
The assistant never reaches further than you do: it acts on your behalf, inside your permissions. Completing also requires the task to be claimed by you — claiming is always a separate step, so you notice if it is the wrong task — and covers one task at a time, never the whole inbox. Every completion made this way is marked in the task history as coming from an assistant, so a later reading tells apart what you typed from what it submitted for you.
The person who administers the process changes this field, on screen. No assistant changes its own permission.
Following an instance
Click any instance to open its detail:
| Information | Description |
|---|---|
| Status | Running, completed, suspended, failed |
| Current step | Which step of the process the instance is on |
| Active tasks | Which tasks are waiting to be done |
| History | Every step already finished, with a record of who did it and when |
| Variables | The data the process carries and uses along the flow |
| Attachments | Files linked to the instance, in the panel opened by the Attachments button |
The list shows, under the process name, which version that instance runs. It matters after a process is republished: instances already running finish on the version they started on, and only new ones pick up the new version. When two instances of the same process behave differently, the version is usually the explanation.
The list comes in pages
The list shows 20 instances at a time, and the footer lets you pick 10, 20, 50 or 100. The number next to the title is the tenant total, not the size of the page — with 137 running you read "137 running" even though only 20 rows are on screen.
The page and the page size live in the screen's address, so a link you copy takes whoever receives it exactly where you were.
History and the result of the variable search come in pages too, with the same footer of 10, 20, 50 or 100 at a time, and the number next to the title is still the total found. Here paging is not a comfort: history only grows, and a tenant with years of execution has tens of thousands of finished instances. On those two screens the chosen page does not go into the address — copying the link takes whoever receives it to the first page of the same filter.
Instance status
| Status | Meaning |
|---|---|
| Running | Executing normally, waiting for the next tasks |
| Completed | Every step finished successfully |
| Suspended | Paused temporarily by an administrator |
| Failed | An automated step failed — including an AI agent step that returned no answer, and a step where the agent declared a blocking issue |
| Cancelled | Ended before completion |
An AI agent step does not land in Failed on the first setback. When the provider does not answer — a timeout, an error on their side, a lost connection — the platform repeats the call by itself, up to the attempt limit configured on the step (two, unless somebody changed it). Only then does the instance show up here. When the failure is the kind that does not improve by repeating — a rejected API key, a quota overrun at the provider, refused content — the step goes to Failed on the first attempt even with attempts left, and the message names the reason and the code the provider returned.
The Reprocess button on this list resumes the step from where it stopped; it does not call the model again. If the answer had already arrived and the failure happened while writing it, reprocessing finishes the step at no cost. If the call itself has to be made again because the attempt limit ran out, whoever designs the process raises the limit on the AI step and republishes.
When an AI step fails
The failure shows where the instance shows — there is no separate screen for it:
- On the instance or case detail, a red strip at the top says how many AI steps failed, and the step is marked in red on the diagram. Click it: the side panel shows the failure type, the reason, how many attempts there were and when.
- On the instance list, the row carries the AI failure badge while the failure is open.
- On the Failed jobs tab (Administrator and Manager), open AI failures are listed above the failed jobs, with a link to the instance. The tab only says everything is healthy when there is neither a failed job nor an open AI failure.
Whoever sees the instance sees its failure, and only that: a regular user does not see the failure of an instance they take no part in.
Administrators and Managers have two buttons on the panel and on the tab:
- Try again. In a case, the AI step runs again — only if it is still active and not already running — and that new model call counts in usage like any other attempt of the step. In a process, the button reprocesses the job that stopped, like Reprocess above: it resumes the step without calling the model again.
- Dismiss. Takes the failure off the list without running anything, keeping who dismissed it and when.
The failure also leaves the list by itself when a later attempt of the same step completes, and when the instance ends (within a few minutes).
Sources of an AI step
When an AI step looked up the knowledge base, its row in the Activity history gets a Sources (n) badge. Click it to see what answered the step:
- the document, the version (
v3) and the place — page of a PDF, section of a Word file, sheet and rows of a spreadsheet, slide of a deck — and the base it came from, with a global badge when it is a platform base; - the first 300 characters of the excerpt, as plain text;
- cited or not cited: whether the step's answer mentioned that document or the label
[F1]; - superseded when the document already has a newer version, and removed when it was deleted — the history keeps showing what the step read at the time. Once the deleted document is purged (end of the orphan window), the source becomes Source removed, with no name and no excerpt.
Administrators and Managers see an Open button, which downloads exactly the cited version (a PDF opens at the page). Other profiles see the excerpt, without the file.
The access level is the viewer's, not the agent's. An agent may read Secret material; whoever does not reach that level sees the source as Restricted source (Secret), with no name, no excerpt and no download. If the document is reclassified, the screen follows the new level the next time it is opened. Once it is deleted, the source is never less restricted than it was when the step read it.
When the answer cites a document or label the step did not retrieve, a yellow Unverified citation badge appears. It is a warning for whoever reviews, made by comparing names — it neither blocks nor changes the answer.
On the task form, a field's Filled by AI mark also lists the cited sources the value came from.
Monitor: where the work is stuck
The list answers one instance at a time. When there are dozens of them, the Manager's question is a different one — where is everything stuck — and that is what the Monitor screen answers.
It shows the process diagram with a number on every step that has work sitting on it. Click the step and the list appears below, with what is there and why:
| Situation | What it means |
|---|---|
| Waiting for a person | A task in someone's inbox |
| Failed | The automated step ran out of retries and stopped |
| Retrying | It failed, but still has an attempt left |
| Waiting for a deadline | Waiting for a date or a configured delay |
| Running | Executing right now |
The count leaves test runs out: the number the operation reads is production. When there are any, the screen says how many just below the total, so that "we tested it" does not stop existing on every screen.
The count includes everything, not only human tasks. A stuck automated step is exactly what no other screen shows, which is why it appears here with the same prominence as a pending approval. A step with nothing stuck gets no number — the diagram already draws it.
The diagram covers one version at a time
A process published more than once has several live versions at the same time: old instances finish on the version they started on, and only new ones enter the latest version. Drawing a single diagram and counting instances from every version on top of it gives the wrong number — a step that only exists in the new version takes the load of the old one, and the load of a step that disappeared from the drawing shows up nowhere.
So the screen draws one version at a time and tells you which: right below the process name you read something like "12 running on v3". If you make no choice, it opens on the version with the most running instances — that is where the Manager's work is — and, on a tie, on the highest one. If nothing is running at all, it falls back to the last published version.
The Version selector, in the top corner, switches the drawing. Each option shows how many instances are running on that version, so you choose already knowing how big each one is; switching clears the selected step, because the steps of one version are not the steps of another.
When work is left outside the version being drawn, a notice at the top says how many instances were left out. The screen never hides work silently — that number is the invitation to switch version in the selector and see the rest.
If the process has written documentation, it appears right below the diagram. It is the same documentation administrators edit in the Process Catalog, and it appears below the diagram there too — whoever is looking at the process reads the text without switching tabs. A process without documentation gets no block at all.
Deadlines and completion time
Above the diagram, a strip sums up the process over the last 30 days (the selector switches to 7, 90 or 365 days):
| Number | What it is |
|---|---|
| Completed | Instances that finished in the window |
| Median and p90 | How long they took from start to end: half finished within the median, nine in ten within the p90 |
| On time | Share of the completed ones that finished within the completion target. Only shown when the process has a target |
| Tasks on time | Share of the tasks with a due date, completed in the window, that finished before it |
| Late now | Tasks and instances that are, right now, past their deadline |
Test runs are left out of every one of these numbers. The strip is recomputed every five minutes. The completion target is set on the definition's Settings tab — see Definitions.
Who can see it
Manager, Admin and Super Admin. A User still sees only their own tasks.
Case instances (CMMN)
Cases work more flexibly than processes. A process has a sequence: the next step is the one the arrow points at. A case has no arrow — it opens at once every step that can already be done, and you choose where to start.
In practice, for the person doing the work:
- A case's tasks arrive under Tasks, next to the process ones, and the CMMN label on the card is how you tell them apart
- When a stage opens with several tasks, all of them are available at the same time: in the onboarding case, "Create Email", "Hand Over Equipment" and "Grant System Access" show up together and can be completed in any order
- The case moves on its own as you finish: completing a task is what opens the next step, and what closes the stage once nothing is left in it
- The history records every activity performed, in what order and by whom
Clicking a case under Instances opens the same detail a process gets: the case plan drawn, with the step in progress highlighted in orange and the finished ones in green, the step history, and the variables the case carries. Clicking a step also shows what was filled in there — that task's own variables, under the label the form gives each field — and an AI step that failed is marked as well (see When an AI step fails, above), as is a step whose automatic job failed, marked with the error message, exactly as in a process.
Attachments work in a case as they do in a process: a file field on a case form accepts upload, preview and replacement, under the same attachment policy configured on the definition.
Monitor covers cases too: the case shows up in that screen's list, the case plan is drawn with the number of instances parked at each step, and clicking a step lists what is sitting there. The reasons are the same as a process's, plus one that only a case has:
| Situation | What it means |
|---|---|
| Waiting to be started | the step was offered and is waiting for someone to start it |
The case plan: what you can tell the case to do
Under the diagram, the case detail carries the Case plan card: the live steps of the case, the state of each one, and the buttons that step accepts at that moment. This is where a step sitting in Waiting to be started stops sitting there forever.
| Button | When it shows | What it does |
|---|---|---|
| Start | the step is Waiting to be started — the model offered it and is waiting for someone to begin | starts the step; if it is a human task, the task now exists under Tasks |
| Discard | the same situation | says this run will not do that optional step, and frees the stage to close |
| Offer again | the step was discarded | takes it back: the step is offered once more |
| Trigger | the step is a user event waiting to happen | tells the case that it happened, releasing whatever depended on the event |
| Close stage | a stage is open and nothing required is left pending inside it | ends the stage, and with it the optional steps still offered inside |
The buttons appear per step and per person: whoever works the case starts, sets aside, offers again and triggers; Close stage is a Manager or Admin action, because it ends work other people could still have picked up. A button that is missing is one that would not fit there — the platform never offers an action the engine would refuse.
Conducting a step does not require a management role, and that is a choice: it would be odd for someone to start a case and then not be allowed to move it along. The limit is a different one, and it is the same one the rest of the screen uses — you only conduct a case you take part in. A case you are not in answers as if it did not exist, exactly as the instance detail does: anyone trying it by address does not even learn that it is there.
A stage closes on its own only when nothing is left inside it. If the model leaves an optional step offered, the stage stays open on purpose, waiting for someone to decide: do the step, set it aside, or close the stage anyway.
Right below it, the Milestones card lists the milestones the case has reached, each with the moment it happened — the points the model marks as "no going back from here".
A step that appeared on its own may be the AI that opened it
A case can contain an AI step, and it opens nothing by itself: it writes a variable, and another step's entry condition reads that variable. So a task that showed up in the list without anyone clicking anything usually came from there — and the reason is in the case diagram, not buried inside the call. The case variables, on the same detail page, show what the AI wrote.
When the agent declares a blocking issue
An agent can be allowed to declare a blocking issue — to say it cannot finish that step, and why: the document never arrived, a required value is missing. When that happens, the step is interrupted and the result variable is not written. No partial answer, no apology text recorded in place of the analysis.
In a case, the case stays open and the step can be run again once the impediment is resolved. In a process, whoever modelled it decides what follows: with an error path drawn for that code, the instance takes it; without such a path, it stops at the step, with the reason named. Whoever started the instance gets a notification, once per step. How to configure it is in AI Agents.
Suspend and Reactivate do not exist for a case
And that is not a missing screen: the case engine has no suspension, a case is either running or finished. So a case row under Instances offers only Details and Cancel. If something calls those addresses anyway, the answer says the action does not apply to a case, instead of pretending the instance is not there. To stop a case, use Cancel.
The case start form
A case can also ask for data before it begins. The case start form is the Form Key set on the case plan — the outer rectangle of the diagram — not on a task. When it is there, starting the case opens the form; when it is not, the case starts straight away, with no variables at all.
That start form is not checked on the server: a blank required field is stopped by the screen, and by the screen alone. The server-side check exists when completing a task, and is described in Forms.
A case that assigns a task by expression needs a start form
If the case's first human task is assigned by an expression — ${gestor}, say — and the case starts with no variables, the start fails with "Unknown property used in expression". The start form is what collects that value: add a field whose key matches the expression (gestor) and point the case plan's Form Key at that form.