A rule opens a case. A person decides it.
Most decisions should run automatically. The few that should not are exactly the ones you will be asked about later.
A service you deploy.
The loop
- A rule flags itthe rule decides what goes to a person
- A case opensqueue, priority, owner
- A person decidesin a screen you declared
- Back into the engineas its own event, recorded like an automatic verdict, with the person and their note
The return arrow: a human decision is an event, decided and recorded like every other, so "who approved this" has an answer without anyone keeping a spreadsheet.
What a rule can open
A case with a queue, a priority, an owner, and optionally a timer. If the timer runs out, the answer was declared in advance — reject, approve, or escalate. The timer is opt-in on the rule that opens the case, because a queue nobody is watching should not be auto-approving things at 3am. A timer with no declared answer is refused when the ruleset compiles.
Moving a case to a senior reviewer's queue is declared per deployment rather than shipped as a fixed feature, so your escalation path is yours. Once a case is decided it cannot be escalated: the server refuses, rather than trusting the screen to hide the button.
The reviewers are part of the design
On queues carrying graphic material, the screen a reviewer works in is declared. An image blurred by default, or a field hidden until someone asks for it, is part of the screen rather than a habit you ask people to keep.
An appeal is a second queue you declare, with its own reviewers, so the person who reviews an appeal is not the person whose decision is being appealed.
Or send it to your own tracker
If your team already works in a tracker, a webhook hands the case to your system and brings the decision back when it is resolved. It is a standard integration.