The process moves only when it has the data and the people to do it.
Two gates a traditional workflow does not have: the Data Gate asks for better data, the WIP Gate asks for available capacity.
- For
- Process owner
- Management
- Compliance
The problem
Many processes jam at two invisible points. The first: a case enters a stage without the data it needs, and automation or AI work on empty fields, producing errors someone will have to fix by hand. The second: a stage receives more work than it can handle, queues grow where nobody can see them, and SLAs fail all at once. These are different problems with the same root: the process accepts work without asking whether it is in a position to do it. The outcome is rework, delays that look sudden, and people spending the day chasing missing information or conflicting priorities. FlowSharp puts two explicit gates into the flow, configurable stage by stage, making visible and governed what used to stay implicit.
Check stage · 3/3
Priority queue
Parking · Data Gate
How it works
1Declare the essential data
For each stage you state which fields must be present before work starts. It is a simple declaration tied to the flow's data schema, making explicit what that stage truly needs to produce a good result.
2Data Gate
If data is missing, the case still enters the stage but stays "awaiting data", with its tasks suspended. It restarts on its own when the data arrives from a form, a task, an integration or an API. The stage timeout stays active, so waiting never becomes a black hole.
3WIP limits
You set how many cases may sit in a flow or a stage: a number, or an expression on a variable (for example team capacity). When the limit is reached you pick one of 4 reactions: warning only, parking with manual override, strict parking, or diversion to another stage (overflow or escalation).
4The queue drains itself
As soon as a slot frees up, the next case enters, by priority if the flow is prioritizable, otherwise in arrival order. Events that arrived in the meantime are set aside and reapplied in order, so nothing that happened during the wait is lost.
Specifications
| WIP levels | flow (blocks new cases) and single stage |
|---|---|
| Limit value | whole number or expression ({{flow.vars.capacita}}); 0 or empty = no limit |
| Reactions | warning · parking with override · strict parking · diversion to another stage |
| Release | by priority or FIFO |
| Queued events | kept and replayed in order, up to 20 per case |
| Override | "Force entry" for Admins only, with a mandatory reason |
| Precedence | the stage timeout always wins over the queue |
| Data Gate | tasks suspended; automatic restart when the data arrives |
An operational example: a full Check stage
Take a Check stage with a work-in-progress limit of 3. Cases A, B and C occupy it: the stage is 3 of 3. Cases D and E arrive. Instead of overloading the stage, they enter a queue ordered by priority: D with priority P1 goes first, E with priority P2 follows. Meanwhile a case can reach the stage without a required piece of data, for example the VAT number. The Data Gate holds it as awaiting data and states clearly what is missing, instead of letting it advance with an empty field. When the data is supplied, the case resumes. The result is twofold: no stage saturates beyond the chosen limit and no case proceeds incomplete. The values in the diagram beside it are illustrative; the behavior described follows the parking, queue and priority rules provided by the flow.
How to verify that limit and gate work
To check the limit, look at the stage: the counter shows active cases against the maximum, and the queue shows order and priority of those waiting. If a case that should advance stays still, open it: the awaiting-data state names the missing field, so the cause is readable without investigation. For the Data Gate, verify that mandatory fields were declared on the right stage and that whoever must supply them has been notified. From a governance angle, every hold and every restart appears in the case history, so you can show that a process did not move on without the required data. If waiting times grow, the queue is a direct indicator: it is worth reviewing the limit or the stage capacity, a decision that stays with the person responsible for the flow and is not taken automatically.
Related features
- Timeouts, SLA and exception routesReadable durations, a destination on expiry, and exception stages reachable only by the system.
- Explainable transition rulesNestable conditions with a default rule: and when a rule does not fire, the history says why.
- Living data contract and flow KPIsDeclared fields and fields observed in real use, with type and provenance, plus flow KPIs.
- Decision ladder: Person, fast AI, generative AIA fast model decides when sure, an LLM restarts from scratch otherwise, and finally a person decides.
- Case workbenchTable, Kanban and calendar with filters built for real operational work.
Use cases
Frequently asked questions
Does the Data Gate block the creation of the case?
No: the case exists and is visible. Only the stage's tasks are suspended until the data is complete, and the stage timeout keeps running.
Do scheduled cases take WIP slots?
They do not take stage slots, but they count toward the flow's WIP limit.
Can an urgent case jump the queue?
Yes, through the flow's priority or with "Force entry", reserved to Admins and traced with a reason.
Why does it matter for AI too?
Because it keeps AI from working on empty or incomplete data: it is one of the safeguards of governed AI.