Plugins and integrations
Make your ticketing system fit the action your team needs.
A transaction exception arrives in the queue. The operator needs to reprocess it in another system, with independent review before it runs and a reference to the result afterward.
A custom plugin adds that action to Latch. Your service owns the downstream operation. Latch checks permissions, applies the configured approval requirement and retains the returned execution result.
Illustrative integration
Transaction reprocessing
- 1. A ticket contains the transaction reference and the operator requests reprocessing.
- 2. The action is configured with maker-checker. A different authorized person reviews it.
- 3. An authorized executor runs the approved request through the provider.
- 4. The provider returns its outcome and downstream reference to the ticket.
This is an integration pattern. Implement and test the operation and credentials for your downstream system.
One extension contract, four control points
01
Offer the relevant action
The provider receives ticket and user context and returns available actions with any input form they need.
02
Request independent review
Configure maker-checker for a sensitive action. The requester cannot approve or execute that request; another authorized person reviews it.
03
Execute after the checks
Approval is separate from execution. Latch checks permission and request state before asking the provider to run the action.
04
Return an inspectable result
The provider returns a message, success or failure, and supported effects such as a comment or status change. The ticket retains the execution outcome.
Keep customization at the right layer.
Start with configuration for queues, permissions and action approval settings. Add a plugin when the workflow needs an operation in another system. Assess a core change when the requirement belongs in the application itself.
Self-hosted ticketing gives you a deployment decision to evaluate alongside that extension work. Enterprise source access adds a licence and maintenance decision.
Test what happens around the happy path.
- An unauthorized user requests the action.
- The requester tries to approve or execute their own request.
- The approval expires or the ticket changes before execution.
- The downstream system accepts the operation but the response times out.
- The provider endpoint or credentials are unavailable.
Plugins versus hard-coded workflows
Decide whether the custom action belongs in a provider or in the application.
Ticketing with approvals
See the complete path from incoming work to review and execution.
Provider and deployment controls
Assess endpoint restrictions, identity and integration responsibilities.
For integration ownership and upgrade planning, read external actions without integration debt.
Evaluate one integration before broadening it
The SDK supplies the contract. Your team still needs a tested downstream operation.
What is a Latch ticketing plugin?
A plugin, also called an action provider, is a service that offers actions for a ticket and executes them when requested through Latch. It connects the ticket workflow to the downstream system your team uses.
Does every plugin action need approval?
No. Approval is configured with a provider default and per-action overrides. Use maker-checker for an action that needs independent review and test the configuration before using it.
Can we add a custom approval rule?
The current gate supports none or maker-checker. Amount-based routing, quorum and multi-step approval chains are not a general built-in rule builder. Review a more complex requirement as integration or application work.
Where does the plugin run?
Your team operates the provider service or integrates an approved endpoint. Its destination must satisfy the provider network policy. Evaluate deployment location and endpoint access together.
Does a plugin replace a source change?
It can keep a custom external action outside the core application. Application behavior may still need source work. Enterprise source code is available under a commercial source licence; assess its terms separately.
What happens if the external outcome is uncertain?
Keep the operation reference and check the downstream system before trying again. Executing and uncertain requests remain blocked until reconciliation. A timeout is not proof that the external action failed.
Bring one action the ticket should control
Name the downstream system, required review and outcome the operator needs to see. Review that path before adding more integrations.