A process app is a drawing that runs. Lanes are roles; boxes are steps, each with a screen; arrows carry the criteria that move the work; decisions are expressions evaluated when a screen completes.
A lane per role, a box per step, a decision where the path splits.
The process configuration screen offers node types to place in lanes. A screen node carries a screen and the role that works in it. A decision node holds an expression evaluated when the previous screen completes: the value of a field, the result of a check, the answer of a function. Parallel split and join nodes run branches side by side and wait for all, or for the first, to finish. A wait node holds until a date, a clock or an event from a system. A notification node informs a role or a person. A write-back node calls a released interface of a system of record. A sub-process node runs another app and waits for its result.
Arrows carry criteria in the same expression language, so the drawing and the rules are one thing. A loop is an arrow back to an earlier box, usually with a note field required on the way.
| Node | Purpose | Typical property |
|---|---|---|
| Start | Where an instance begins: a form, a criterion on records, a schedule or an event | Trigger criterion |
| Screen | A step a role performs on a screen | Screen, role, period active |
| Decision | Chooses the next arrow from an expression | Expression; default arrow |
| Parallel split / join | Runs branches at the same time; joins on all or first | Join rule |
| Wait | Holds until a date, a clock or a system event | Event and timeout |
| Notification | Informs a role, a level or a list | Channel, template |
| Write-back | Calls a released interface and stores the acknowledgement | Interface, mapping, retry |
| Sub-process | Runs another app and waits | App and version |
| End | Closes the instance and the log | Outcome code |
Each screen node names a screen from the app's screen list, or a new one drafted from the data handlers it needs. The node's properties say how long it stays active, which exceptions it raises when the clock runs out, how variables are exchanged with the next node, and which emails and notifications go out when it starts and when it ends.
Because the screens are ordinary screens, a box can show a grid of live purchase order lines, a chart of the supplier's history and a decision panel side by side, on one screen, read in place through data handlers. The same screen can be used by two boxes, for example a customer's view of a claim and an agent's view of the same claim, with visibility rules on the components deciding what each role sees.
| Property | What it does | Example |
|---|---|---|
| Screen associated | The screen the role works in at this step | S02 Line detail |
| Period active | How long the step waits for the role; then the exception rule runs | 8 working hours |
| Exceptions | What happens on timeout or on an error from a system | Escalate to the buyer lead; retry the write 3 times |
| Variable exchange | Which app variables the step reads and sets | sets app.decision, app.new_date |
| Templated mail on start or end, with a link to the workbench | Supplier asked: new date needed by Thursday | |
| Notifications | Slack, Teams or in-app cards with action buttons | Approve / Return / Escalate buttons on the card |
Roles can be inside or outside the company.
A lane belongs to a role, and people are attached to roles, so an app is defined once and staffed many times. A role can be internal (buyer, controller, quality engineer), external (supplier, carrier, customer, auditor) or a system (the ERP that receives the write-back). External roles work on portal screens: the same screens, delivered to an outside login, with the access policy deciding which rows the outside party sees.
Roles carry scopes, so a buyer role can be staffed per purchasing group and a supplier role per vendor number. When an instance starts, the platform resolves the person for each role from the instance's data: the buyer of the purchasing group on the order, the contact of the vendor on the order, the planner of the plant.
One expression language for start, arrows, decisions and clocks.
The start criterion decides when an instance begins: a form submitted, a record that matches a condition on live rows, a schedule, or an event from a system such as a goods receipt or a Change Data Capture message. Arrow criteria decide the path: a claim below the band goes straight to the write-back node, a claim above the band goes to the assessor. Clocks decide time: a step active for 8 working hours, then the exception rule.
Every criterion is tested where it is written. Pick a live row, and the editor shows the value of the expression for that row; change a threshold, and the count of rows the start criterion selects updates as you type. A criterion that references a field the data handler lacks is flagged before the drawing is saved.
A serial number, a coverage check, a claim decision, a service order.
A screen collects answers and a flow routes them: requests, registrations, attestations, declarations.
Read the page →A survey is a screen sent to a list of people or a level, with a close date; the answers are rows that any other app can read.
Read the page →A process whose steps compute: a pipeline handler runs a calculation between two screens, for example a margin or a projected stock, and the next screen shows the result.
Read the page →A process app started by a criterion on records: each matching record launches its own instance, with its own process ID and workbench.
Read the page →The drawing uses the same ideas people know from process notation: lanes, tasks, gateways, events. Lima keeps the vocabulary plain (lanes, boxes, decisions, waits) and keeps the drawing and the rules in one place, so the picture on the screen is exactly what runs.
Yes. A write-back node, a pipeline handler or a function runs with a person watching the log while the system acts. Where a step should decide by rule, a decision node with the rule replaces the screen.
Each outside role works on portal screens under its own login. The access policy limits what each party sees, the signatures node lets both sign the same version, and the log shows both sides' steps in one record.
The node's exception rule decides: retry on a schedule, hold the instance in a wait node, or route to a person. The acknowledgement is stored only when the system confirms, so the log always says what happened.
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.
