Governed approval workflows enforced at the platform level
Refunds, vendor changes, account modifications, escalations — some actions need a second pair of eyes before they run. Latch adds the approval step, checks the reviewer's role, and records what happened.
Request → review → execute → record
AI suggests, humans decide
AI can suggest the next step, but a person still decides when a sensitive action actually runs. The suggestion and the decision are both recorded.
Maker-checker enforced at the system level
For actions that require independent review, the person who prepared the case cannot approve it. Role separation is a hard constraint, not a policy reminder. See how maker-checker works →
The result goes back on the record
After the action runs, the case still tells the full story: what was requested, what was approved, what happened. That is what makes control real instead of theoretical.
Questions about approval steps
Common questions about how Latch handles approval workflows for sensitive actions.
How are high-risk actions approved?
The system checks the operator's role and permissions before the action can run. If the operator is not in the right role, the action is blocked. The goal is to keep sensitive work inside the case instead of routing it through email or chat.
How is separation of duties enforced?
Latch limits who can run each action based on their role. The person who prepares the case and the person who executes the action can be required to be different people. Both steps are recorded on the case.
What happens if an action is denied or unavailable?
Blocked and unavailable actions show up in the case history. The operator can see why it was blocked, and anyone reviewing the case later can see what was attempted and why it did not go through.
How are plugin actions reflected back into the case?
When a plugin runs an action on an external system, the result comes back to the case automatically — including any comments, status changes, or updates. The case stays the single source of truth.
What about maker-checker and four-eyes workflows?
Latch supports full maker-checker enforcement: the person who prepares the case cannot approve it. Role separation is enforced at the system level, not through policy. See the maker-checker page for details on how dual control works inside the case.
Pick one sensitive action and see how the approval step works
Start with a refund, a vendor change, an account modification, or a customer escalation — and see how Latch adds the approval step, connects the external system, and keeps the record.