Processes lets authorised users start and inspect configured process instances and act at the steps assigned to them.
When you start a process — request an approval, run an exception, launch a programme — it runs as an instance: a live thing with a status, a current step, a payload, and a trail. This manual covers what you see of a running process and what it records as it goes.
What runs and what you see
The process instance
| What it carries | What it means when you look |
|---|---|
| The manager it runs | Which process definition the instance is — the approval flow, the onboarding sequence |
| The status | Running, waiting, completed, failed — the honest states, with the failure reason when there is one |
| The current step | Where the work is right now |
| The payload | The data the process carries between steps — what the approval is about, what the exception contains |
| The actor | Whose process it is — the initiating actor and any configured execution identity provide the context for authorised work |
| The activity trail | Started at, last activity, completed at; who created, who updated — and the update reasons |
Identity matters for daily work: a human approval should identify the approver and the decision. Background work and external integrations may use separately scoped execution credentials; inspect both the business actor and the executing service where applicable.
The steps
Each instance travels typed steps — approvals wait for the approver, exceptions wait for the resolution, gates wait for the human decision. The step knows its own rules; the process knows its own path; you see where things stand without asking anyone.
The states, honestly
Stalled, waiting, failed — these are statuses, not embarrassments. A process instance that records "waiting for approval since Tuesday" is doing its job: the wait is visible, the wait is measurable, and the bottlenecks your operation experiences become data instead of folklore.
What you can do
- Start processes — from the surfaces your operation exposes: a request, a form, a conversation with the assistant
- Watch your instances — status, current step, payload; the list is yours
- Act at your steps — approve, reject, resolve, escalate — under your own identity
- Read the trail — what happened, when, through which steps; per instance
- Run what's available — the processes your operation has defined and exposed to your role
Where it connects
The instance is connected to the entities it carries: the work it moves, the record it updates, the approvals it gathered. The process surface is part of the same relationship layer — a running approval relates to the request, the approver, the outcome.
Where it feeds
The running instances are the process evidence: where work waits, which steps gate the flow, how long the exception took — Process Orchestration analysis draw from these trails. Your daily process work is the evidence; this manual is the surface it happens on. The orchestrator story is the deep page; this manual is the daily surface.
The pattern note: same four-part structure — record (the instance), do (start/watch/act), connect (the carried entities), feed (the process evidence). The processes manual is where the identity pattern lands for the end user: inspectable actor context at the steps you review.
Implementers compose your first processes with your team and configure the surfaces your roles see; consultants help define the flows whose paths match how your organisation actually decides.
No record is an island
Every instance relates to the work it carries, the approvals it gathers, the people who act at its steps. The process is not a black box here — it is a connected, traceable, honest record of how the decision traveled.
Review the record and its context before deciding what to do next.
Projects → · Reports → · All manuals → · The Orchestrator platform page →
Check your work
Open the relevant instance and check its definition, current state, actor context and available trail. At a decision step, inspect the request before approving or rejecting it. If execution fails, inspect the recorded failure and recovery rules before retrying; a retry may repeat an external effect unless the integration handles it safely.
Available screens and actions depend on your deployment and permissions. Use this manual alongside the configured workflow and the capability demonstration for your installation.