The Process Inspector

The Process Inspector shows, in plain words, how every approval process on the system is configured: where requests start, who is e-mailed at each stage, which fields each approver sees, what they can do, and what happens if nobody acts. It changes nothing, so it is safe to give to people who need to understand a process but should not edit it.

Where to find it

Architect Panel → Forms:

Process Inspector — every architect sees it, with edit pencils beside each setting

Admin Panel → Processes:

Process Inspector — read-only, once granted to a security group

The Admin Panel tile ships visible to nobody. Whoever opens either tile sees only processes whose datastore they hold Read on.

The list

The first screen lists every process you can read, with its datastore, the number of stages (counting the form itself as stage 1) and the reference prefix. Open one to see its detail.

Inside a process

The heading: datastore, number of stages, reference prefix, and whether declined requesters may re-apply.
A task warning, if any time-out, reminder or delayed e-mail on the process depends on a scheduled task that is not installed, switched off, or enabled in a way that will not run. Each line names the task and the stages affected.
Process settings: Where a request starts (Initial Stage Assignment), Where it ends (the Process Complete Action) and Custom code (a first-stage callback, if any).
E-mails sent by this process: who the requester is, and each requester e-mail (confirmation, approved/progress, completion, declined, cancellation, request for more information) with its template.
Flags raised by the answers: the flag rules, if the view has any.
Application windows: whether the intake bindings are complete, how many rounds are open today, and anything that would refuse applications. See Application Windows & Shortlisting.
Stages, in the order a request travels, with a rail to jump between them. Each stage has:
- On arrival: what happens when the request reaches it.
- The approver: what they can do, and the extra questions each button asks (Also asked for), which are stored against the decision rather than on the record.
- Timing: If nobody acts in time, Reminder e-mails, and Reminders while waiting for more information.
- Fields shown at this stage: which fields the approver reads and which they can change.

Amber means switched on but empty

A setting set to Yes with nothing filled in, such as a time-out with no period, is shown in amber rather than as a plain Yes. Every task that reads those settings skips them, so they look on in the builder and do nothing. Fix them in the builder.

Using it to answer questions

"Why did this go to Jane?" Read Where a request starts, then On arrival for that stage.
"Why has it sat there a fortnight?" Read Timing for the stage, then the task warning at the top.
"Where did the decline reason go?" Read Also asked for: it is stored with the decision and shown on the request's progress page, not on the record.
"Why is the form refusing applications?" Read Application windows.

For architects

Opened from the Architect Panel, the screen shows a pencil beside each setting. Most open the row editor for the view or stage; the pencils beside The approver and Fields shown at this stage open Form Stage Actions and the visibility override. Stage 1 has no row of its own, so it has no pencil.

Worked example

A hospital's HR team asks why reminders stopped on its Study Leave process. An architect grants the Admin Panel tile to the HR managers' group, and the HR lead opens the process. The task warning reads that the reminder task is switched off for stages 2 and 3, and stage 3's If nobody acts in time is amber. The architect enables the task, fills in stage 3's time-out, and the HR lead re-opens the inspector to see both warnings gone.

Recommendations

Grant it to process owners; it is read-only.
Check it after every change to a process.
Treat amber as a fault to fix, not a style.
Start with the task warning when something timed is not happening.