Most teams hit the same wall. The case lives in one system. The action that resolves it lives in another. The operator switches tabs, does the work in Stripe or the ERP or an internal admin panel, switches back, and types a note: "refund processed."
That note is not evidence. It is a memory.
A plugin action is the alternative. It is a step that runs on an external system — Stripe, an ERP, Slack, an internal API — from inside the case, with role checks, approval steps, and an audit trail attached automatically.
This is for:
- Operations leads who want one place to review and act, not a five-tab workflow
- Engineers who want to connect external systems without building custom approval and logging code for each one
- Anyone who has had a manager ask "who approved that?" and realized the answer was buried in a Slack thread
The Problem in Three Parts
1. The action happens outside the record
The operator resolves a refund in Stripe, closes a case in the internal system, and the two records are connected only by the operator's memory. If someone asks what happened six weeks later, the answer requires reconstructing the sequence from timestamps across multiple systems.
2. Permissions are informal
Who can process a refund? In most setups, anyone with Stripe access. The role checks that matter (threshold limits, approval requirements, separation between reviewer and executor) live in process documents, not in the system. They hold until they do not.
3. There is no audit trail on the action itself
The case system might record that the status changed. It does not record what the operator requested, what the external system returned, whether the action was approved or denied, or what happened if it failed. The evidence gap grows with every action that crosses a system boundary.
How Plugin Actions Work
A plugin action follows four steps. Every step produces a record.
Step 1: The plugin receives the case context. When an operator opens a case, the plugin sees the case type, metadata, and current state. It decides which actions are relevant to this case and hides the rest. A refund action appears only when the case involves a refund-eligible transaction. A vendor update action appears only when the case involves a vendor change. The operator sees what they can do, not everything the system can do.
Step 2: The operator picks an action. The available actions appear inside the case. The operator selects one — "issue refund," "update vendor record," "notify the team" — and confirms the details. This selection is recorded.
Step 3: Role checks and approval steps run. Before the action fires, the system checks whether this operator can run this action on this case. If the action requires a second reviewer (two-person review), the action waits. If the operator does not have the right role, the action is blocked — and the denied attempt is recorded. None of this happens in a side channel.
Step 4: The action runs and the result writes back. The plugin sends the request to the external system. Whatever comes back — success, failure, partial completion, error details — writes into the case timeline automatically. The operator does not need to type a note. The evidence is structural.
Where Latch Fits
Latch is built around this pattern. Every plugin action in Latch follows the four-step model: context-aware discovery, operator selection, permission and approval enforcement, and result capture.
If your team processes refunds through Stripe, start with how plugins connect external systems or talk through the workflow directly.
If the question is less about the external system and more about the approval step, see how two-person review works in Latch.
What Makes This Different from a Webhook Button
Teams sometimes build quick integrations: a button in the case that fires a webhook to an external system. That solves the tab-switching problem. It does not solve the other two.
A webhook button has no role checks — anyone who can see the button can click it. It has no approval step — the action fires immediately. It has no structured result capture — the team learns what happened by checking the external system directly.
A plugin action is different because the infrastructure is built in. Permissions, approvals, and audit trails come from the platform, not from custom code on each integration. Adding a new external system does not mean rebuilding that infrastructure from scratch.
What This Means for Small Teams
A five-person team processing refunds in Stripe and tracking work in a spreadsheet does not need a governance platform. They need one thing: when someone asks "who approved that refund and what did Stripe return?", the answer should be findable in one place, not reconstructed from three.
That is what a plugin action does. It keeps the work, the decision, and the evidence together — regardless of where the actual action runs.