A queue with context
Tickets bring ownership, status, evidence, comments, and activity into the operator view. Your workflow still needs clear field definitions and handoff rules.
Platform teams · Build vs buy
Build your workflow on ticketing you can adapt
The internal tool starts as a form and a table. Then the next request needs supporting evidence, another person's approval, a call to the payment service, and a record of what came back.
Start with Latch's ticket lifecycle, permissions, and independent action review. Configure what the team captures and build the connections specific to your business. Source code is available on Enterprise under agreed commercial terms.
Adaptation choices
Estimate the change and the maintenance
A new field, an external action, and a bespoke screen have different owners. Separate them before estimating the build or comparing products.
| Requirement | Approach | Work your team owns |
|---|---|---|
| Different ticket information | Configuration | Maintain tags, Issue Data Fields, required evidence, and reports. Test changes against the records your operators already use. |
| An action in your payment service or ERP | Plugin or API | Build and operate the connection. Maintain business rules, endpoint access, credentials, error handling, and reconciliation. |
| A behavior beyond supported extension points | Enterprise source change | Agree modification and support rights. Maintain the change, its regression tests, and its compatibility with releases and migrations. |
| Control over the deployment | Customer-operated installation | Operate infrastructure, database, durable attachments, identity, network access, monitoring, upgrades, backups, and recovery. |
Read the configuration, plugin, and source-change guide and review Enterprise source-access terms.
Evaluate the existing foundation
Test the parts your workflow depends on
Use a request that resembles the work your operators handle. Verify access, independent review, execution, and failure evidence before deciding what your team needs to build.
Independent action review
A sensitive plugin action can require another eligible person to review its saved request. Approval and execution remain separate steps.
Supported integration contracts
Use the API or TypeScript and Go plugin SDKs. Verify the current contract and supported endpoint policy for the action your service implements.
A record beside the work
Keep the request, review, and result reported by the plugin connected to the ticket. Define any downstream reconciliation and external archive requirements.
See ticketing with independent approvals, custom ticket actions, and action history and exports.
Illustrative customization
A vendor bank-detail change
Fields capture the proposed account change and supporting evidence. A customer-built plugin exposes the ERP update; the action requires another eligible operator to review the saved request before execution.
The plugin implements the ERP-specific rules and returns its result to the ticket. Your engineers maintain the integration and reconcile that result with the ERP record.
This is a hypothetical connection to explain the extension model, not a claim of a supplied ERP connector or a customer deployment. The fields are configuration, the ERP call is a plugin, and a new bespoke screen would be a separate source-change decision.
Deployment
Operate the system where it fits
Run Latch in your environment or private cloud. Review every configured service, including identity, durable attachments, email, models, and integrations.
The self-hosted ticketing page explains the installation and customization choices. The security review maps data flows and responsibilities.
Maintenance
Include the next upgrade in the decision
Test the workflow with custom integrations enabled, rehearse recovery, and agree support for any source changes. Adopting a product changes what your team maintains; it still needs an owner.
Use the deployment evaluation checklist and compare Enterprise deployment options.
Platform teams Q&A
Questions behind the build-versus-buy decision
Compare the supported product behavior with the custom code and operating work your team still needs.
When does adapting Latch fit better than building?
It fits when your requirement is a ticket lifecycle with evidence, permissions, independent action review, and connections to existing systems. Compare those supported behaviors with your exact workflow, then identify the configuration and integration work your team still owns.
When is building the right choice?
Building can fit when the workflow is the product you sell, or when it has a small scope that a form and a status field cover. Include long-term ownership, access checks, evidence, failure handling, and maintenance in that decision.
Do custom actions require a product fork?
Supported APIs and plugins let your team add connections without changing the core application. A request beyond those extension points may require an Enterprise source change, subject to the agreed licence and support terms.
Is source access available?
Source code is available on Enterprise under commercial terms. Review the agreement for the access, modification, deployment, redistribution, and support rights that apply to your proposed change.
Can we operate the product in our own environment?
Yes. Enterprise supports a customer-operated deployment. Include identity, durable storage, models, mail, integrations, network policy, upgrades, and recovery in the operating plan.
Who maintains the custom plugin?
Your team operates its plugin and maintains its business logic, credentials, connectivity, downstream behavior, and release compatibility. Latch supplies the supported application request, review, and execution path; the connected system needs its own controls.
Workflow review
Bring the workflow you are about to build
Follow one request through fields, independent review, a connected action, and its recorded result. Identify the work your team owns.