Most exceptions in a business are rows: a late order line, a blocked invoice, a stock position with a year of cover, a count that differs from the book.
The starting point is data that already exists.
In a data-driven app the starting point is already existing data. The app operates from identified and isolated records: a criterion, written and tested on the live tables, marks the rows that need a decision. The platform stores the list, attaches to each record the app flow that will handle it and the people who own it, caches the record lists per person so each owner sees their own queue, launches the app per record with a unique process ID and workbench that isolates the end-to-end flow, monitors each flow until it finishes, and logs every step centrally from start to finish.
The criterion is the heart of it. It is an expression on the fields of one or more data handlers, for example open order lines whose delivery date is within five days and whose received quantity is below the ordered quantity. The editor shows the rows it selects as it is typed, so the threshold is right before the app runs.
Owners are attached by rule too: the buyer of the purchasing group on the order, the steward of the material's domain, the plant controller of the cost center. When the rule finds nobody, a default owner receives the record and the gap is reported.
A workbench is the running instance seen by its owner: the screens of the flow in their current state, the process ID, the step the instance is on, the clock on that step and the log so far. Because each record has its own instance, two late lines from the same supplier are two workbenches with two logs, and a board aggregates them for the buyer lead: how many, how old, what value, which ones escalate today.
The same pattern serves control-tower exceptions. The Backbone's checks and exceptions raise the rows; a data-driven app is where people decide on them, with the decision written back and logged.
From the criterion at 08:14 to the order updated in the ERP.
On a schedule you set, or on change capture where the source supports it, so a new match appears within minutes. Resolved rows close their instances automatically when the criterion stops matching, with the log recording why.
Both instances exist and both logs refer to the same row; a board can show them together. A rule can also give one app precedence and suppress the other.
Yes. An agent can propose the decision on each record and the person accepts or changes it in the workbench; within stated limits the agent can act and the person reviews the log. The instance and the log are the same either way.
The criterion runs in the source through the data handler, so the size is the source's business. Lists of tens of thousands of rows are cached per owner; the board aggregates them.
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.
