Most teams hit the same wall. The ticket lives in one system. The action that resolves it lives in another. The operator switches tabs and does the work in Stripe, the ERP, or an internal admin panel. Back in the ticket, the operator types a note: "refund processed."
That note is not evidence. It is a memory.
A plugin action is the alternative. It runs on an external system — Stripe, an ERP, Slack, an internal API — from inside the ticket. Role checks, approval steps, and an audit trail attach 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 has realised the answer was buried in a Slack thread.
The Problem Has Three Parts
1. The action happens outside the ticket record
The operator resolves a refund in Stripe, then closes the ticket in the internal system. Only the operator's memory connects the two records.
Six weeks later, someone asks what happened. 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. The action carries no audit trail
The ticket system might record that the status changed. The request, the external response, the approval or denial, and the failure details stay outside it. The evidence gap grows with every action that crosses a system boundary.
Plugin Actions Work in Four Recorded Steps
A plugin action follows four steps. Every step produces a record.
Step 1: The plugin receives the ticket context. An operator opens a ticket. The plugin sees the ticket type, metadata, and current state. It decides which actions are relevant to this ticket and hides the rest. A refund action appears only when the ticket involves a refund-eligible transaction. A vendor update action appears only when the ticket 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 ticket. 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. The system checks whether this operator can run this action on this ticket. An action that requires a second reviewer (two-person review) waits. The action is blocked when the operator does not have the right role. 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 ticket timeline automatically. The operator does not need to type a note. The evidence is structural.
Latch Runs Every Plugin Action through the Four-Step Model
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.
See how two-person review works in Latch when the question is about the approval step, not the external system.
A Webhook Button Solves Only the Tab-Switching Problem
Teams sometimes build quick integrations. A button in the ticket 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.
Small Teams Need the Answer in One Place
A five-person team processing refunds in Stripe and tracking work in a spreadsheet does not need a governance platform. The team needs one thing. The answer to "who approved that refund and what did Stripe return?" 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.