Watch a Process Run

Goal

See what your process has really done: every run of it, and — for any one of them — each step it took, in order, with the reason it stopped if it did.

Prerequisites

• The process is published. A draft has never run.
• You are a maker in the environment.

Where it is

Open the process and select Runs on the rail, beside Flow and Coforms. It is the only entry there that is not something you edit: the other two are the process, this is its history.

The list

Every run, newest first — the opposite of your task list, and deliberately: a queue is worked oldest-first because the oldest has waited longest, but somebody opening a run list is nearly always asking about the one that just happened.

Each row shows when it started, whether it is Running, Completed or Cancelled, the version it started on, and Waiting on.

"Waiting on" is the column to read

It names the people the run is still with. It is what tells a healthy run from a stuck one:

• Names — the run is waiting for those people, which is normal and is not a problem. A step offered to everybody holding a role names the first three and then says how many more; a step one person has already taken names that person.
• Nobody, on a run still marked Running — this is the one to look at. Nothing is waiting for a person and it has not finished, so it stopped somewhere. Open it.

It also reads Nobody when a step is open but its assignment resolved to no one — a task that exists and is in nobody's list. That is the same thing to go and look at, and the history says which step and why.

note

A name you do not recognise, or something like systemuser:9f3c…, means the environment could not answer for that person — usually a user who has been removed since the task was raised.

Who is holding it up

Under the diagram, a run with anything still open lists Waiting on: one row per step it has not got past, with the people it is with, when it started waiting, how long it has been waiting, and when it is due.

This is the answer to the question a stopped run is usually opened with. The history says what has already happened and the diagram says where the run got to; neither says who has to act next.

You cannot do those tasks here, and that is deliberate. This is the maker's view of the machinery, and it does not run under the permissions of the person the task is for. The work is done in the Platform Shell: open the app, then the task tray in the top bar.

Handing a task to somebody else

There is one thing you can do to a task from here: Hand on, on the row.

Use it when the person the task is with cannot do it — they have left, they are away, the work was routed to the wrong group. Select Hand on, choose somebody, and confirm. The task leaves whoever had it and is offered to the person you named; they take it by opening it, exactly as they would any other task.

This is a different power from the one in the Platform Shell, and it is worth knowing which you are using. The Hand on in somebody's own task list can only be used by the person holding the task — it answers "I am going away". This one is yours because you can open this screen at all, and it answers "somebody has gone away". Either way the task must still be open: a decision that has already been taken cannot be handed on.

The run, step by step — on a diagram

Select a run, and above its history you get the run drawn.

It is not your diagram with the current step lit up, and that difference is the point. A run visits a step as often as it likes: a rejection that sends work back visits the same step three times, and lighting it up shows you one box that has been visited — not the three visits, not their order, and not which one you are looking at.

So the run is unrolled. One shape for each step the run took, laid out left to right in the order they happened, in your own shapes and your own swimlanes:

• A step reached twice appears twice, and the second one says pass 2. The third pass is the third column, so a loop reads forwards instead of as an arrow doubling back.
• A fork's routes are parallel rows, each staying on its own line for as long as it lives, and the join draws every one of them into the step the process carries on at.
• Where the run is now is outlined in amber and says here now. Where a route stopped is outlined in red and says stopped here.
• The lanes are yours. One band per lane, not one per pass — a lane is a person, and two "Manager" bands would be two rows for one of them.

The history itself has five columns: when it happened, what happened, the step it happened at, that step's type, and any detail the event carries — a branch's edge, a deadline that passed, the reason a token stopped.

The step column reads the step's name, the one you gave it in the designer. It used to print the id the designer generates — n-start, n-3 — which told nobody anything. A step the process no longer has still shows its id, because that is the only true thing left about it.

Click a shape and the history below narrows to that step: what the engine did while the process was there, and nothing else. Show the whole run puts it back.

It is drawn against the version that is running

A run finishes on the version it started on, even if you have published twice since. The diagram follows the run, not the current draft — so what you are looking at is what actually executed. If that version is no longer stored, the diagram is not drawn and the history is shown on its own.

What happened, step by step

The history appears in the order it happened:

You will see	What it means
Run started / Run ended	The instance itself
Reached	The process arrived at that step
Branched	A branch chose a way out, and which connection it took
Split / Joined	A fork made several routes at once, and a join brought them back
Task raised / Task completed	Work went to a person, and came back. A completed task says which button they pressed and who they were
Route ended / Route cancelled	One route finished — a process with a fork has several
Stopped	The one that matters: the process could not go on, and the reason is written out

Stopped is why this screen exists. A process that stops — a branch where no condition was true, a script that would not parse, a task that could be assigned to nobody, an outcome with no connection leaving it — records exactly what was wrong at the moment it happened. That sentence is the answer to "why did nothing happen".

A very long run

A run that looped thousands of times has more history than the screen shows. When that happens it says so: the earliest steps are listed and the rest are not. It never quietly shows you the first few as though they were the whole story.

A run with very many routes

A run that forked more times than the diagram can draw says so above it: some branches are missing from the picture. The history underneath is unaffected — it is the complete record either way.

Taking hold of a run

Watching is not the only thing this screen does. Along the title bar are the controls a run that is still going offers — a finished run offers none of them, because there is nothing left to hold, let go, or stop.

Pause

Pause holds the run. Every route, every task and every deadline stays exactly where it is, and nothing moves until you resume it. The run reads Paused rather than cancelled, which matters: a paused run is alive, and somebody who read "cancelled" would go and start the process again.

Use it when a run is doing something you did not intend and you need a moment to look at it — before this, the only way to stop a run doing the wrong thing was to cancel it, which cannot be undone.

Resume

Resume lets it go again, from exactly where it stopped.

One thing to expect: a timer that came due while the run was paused fires straight away. The moment passed, and the run is not given it back — a step that was waiting until Friday and is resumed on Monday takes its step on Monday.

Stop

Stop ends the run for good. Every route stops where it stands, and the tasks it put in people's inboxes are withdrawn — nobody is left holding a decision with no process behind it. The process's own On cancel handler runs, which is the one moment it ever runs.

You are asked to confirm, and asked why. The reason is optional — "stop it" is a complete instruction — but it is written into the history, which is where the next person to ask "what happened to this one" will look.

A stopped run cannot be started again from here. Start the process afresh instead.

A route that stopped, and trying it again

When a route could not take its step, the run grows a Stopped routes panel above the open tasks: one line per route, naming the step it stopped on, with Try again beside it.

The history says why it stopped — a branch where no condition was true, a script that would not parse, a record that was not there. Fix that cause first; then Try again puts the route back on the step and asks for it a second time.

Two things worth knowing:

• It runs the version the run is on, like every other step. Republishing the process does not change what a run already going executes, so a fault in the drawing is not fixed by republishing and retrying — that run will keep failing the same way. What retrying is for is the cause that has since gone: a record that was missing, a service that was down, a setting nobody had filled in.
• Only on a run that is still going. Routes on a stopped run are not offered a retry: restarting one would be restarting a process somebody deliberately ended.

Moving a run onto a new version

You cannot, and that is deliberate. A run finishes on the version it started on. There is no way to move one onto a newer drawing, because the two documents need not have the same steps at all — the run is standing on a step the new version may have renamed, moved into another lane, or deleted, and no rule the platform could write would guess right about which of those it is.

What to do instead: publish the new version, so every run started from now on uses it, and let the ones already going finish. Where a run in flight genuinely has to follow the new design, stop it, say why, and start a fresh one.