Configure the model, the screens, the data and the flow; test each piece as you go; preview the app as each role on live rows; publish a version with a note; run instances with their own process IDs; monitor them on a board; log everything centrally.
Testing is part of configuring. A person building the late-order app types the criterion and sees 31 rows; changes the threshold to 3 days and sees 19; picks one and sees the buyer the ownership rule resolves. A screen drafted from the handlers renders on those rows at once. A change and its test are the same moment, so a working day of configuration is a working day of results.
The studio keeps the whole definition consistent: renaming a component updates every expression that uses its ID; removing a handler is refused while a screen still binds to it, and the screen is named; a criterion that references a field the handler lacks is flagged before the save.
Preview runs the app end to end as any role you choose, on live rows, with writes held: the buyer's screen, then the supplier's portal screen, then the buyer lead's escalation, with the log filling as if it were production and every write-back shown as it would be sent. When the preview matches the process, the app is published as a version with a change note and the roles assigned.
Publishing is a promotion between environments with a gate: the configuration environment holds the draft, production holds the published versions, and an approval with a note moves a version across. Running instances keep the version they started on; new starts take the new one; a version can be withdrawn with one action, and the previous one takes new starts.
| Stage | Who | Gate |
|---|---|---|
| Draft | configurator | validator passes |
| Preview | configurator, process owner | preview as each role signed off |
| Publish v1 | process owner | approval with a note; roles assigned |
| Promote | application team | promotion gate: approval, checks, write-back switched on per object |
| Run | the roles | instances start by the trigger |
| Change | configurator | new version; instances finish on their own version |
Each start of a process is an instance with a unique process ID and a workbench that isolates its end-to-end flow. The board shows every open instance by step, age, owner and value, with the clocks about to run out first. The central log records every step, every value shown and entered, every decision, every notification and every write-back with its acknowledgement, across all instances and all apps, append-only.
Operations teams watch the same board for the platform: instances stuck at a write-back because a system is down, clocks expiring on unowned steps, and apps whose start criterion selects far more rows than usual.
A first running screen in about 30 minutes; a production-grade app in 2 to 10 working days according to the catalogue's estimates, most of it spent agreeing screens and criteria with the process owner, because the building itself is quick.
Yes. Publish a new version; running instances finish on theirs, new starts use the new one. A withdrawn version hands new starts back to the previous one.
Every change to a definition is a versioned, logged entry with the person and the note; the app's history is readable like an instance's log.
An app definition is data: export it from one environment or deployment and import it into another; handlers are re-bound to the local catalog.
Bring one process and the systems it touches. In the first session we register the data handlers, draw the levels or the lanes and run the first screen on your live rows.
