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.
Built into the Swiftward service you run.
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
Because the reviewer's decision goes back into the engine as an event, "who approved this" is answered from the record, and nobody keeps a spreadsheet.
What a rule can open
A case with a queue, a priority and an owner. A timer is optional and off by default, because a queue nobody is watching should not approve things on its own at 3am. When the timer runs out, the case gets the answer you must declare in advance: reject, approve, or escalate.
Each deployment declares its own escalation path, such as a senior reviewer's queue. 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
The screen a reviewer works in is declared, so a queue carrying graphic material can protect the people who work it. 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 standard webhook integration hands the case to your system and brings the decision back when it is resolved.