Application and workers
Run the ticket interface, API, and background work on infrastructure your team operates.
Self-hosted ticketing
Self-hosted ticketing you can adapt to your controls.
Your team needs the queue to follow its own data, access, and review requirements. Run Latch in your environment and keep tickets, attachments, and action history on infrastructure you operate.
Configure the fields, connect the actions your team needs, and require independent review where the work carries risk. Source code is available on Enterprise under the agreed licence terms.
Four decisions to make
- What runs where. Map the application, storage, identity, models, and connections.
- What needs to change. Separate configuration, plugins, and source changes.
- Which actions need review. Keep the saved request beside the evidence before it runs.
- Who maintains it. Name the owners of upgrades, recovery, and custom code.
Customizable ticketing
Choose the change that fits the requirement
A required evidence field, a call to your payment service, and a bespoke screen need different approaches. Each carries its own maintenance work.
| Requirement | Method | Example | Responsibility |
|---|---|---|---|
| Capture the details your team needs | Configuration | Set up ticket tags and Issue Data Fields, required evidence, saved views, and reports. | Your workflow owner maintains the fields and checks how changes affect existing records. |
| Run an action in another system | Plugin or API | Expose a payment reprocess action through a service your team builds and operates. | Your engineers maintain business rules, credentials, connectivity, and downstream behavior. |
| Change the application itself | Enterprise source access | Review a proposed screen or behavior that goes beyond supported configuration and extension points. | Agree modification and support terms first. Your team tests and maintains its changes through upgrades. |
See the configuration, plugin, and source-change decision guide, the plugin system, and the Enterprise source-access boundary.
One request, end to end
Review a transaction reprocess before it runs
A payment exception reaches the queue. An operator prepares a transaction reprocess request; another eligible operator reviews the saved values beside the supporting evidence.
Prepare the request
Capture the transaction reference and retry reason. Submit the action details from the ticket.
Review, then execute
A different eligible operator approves or denies the request. Approval makes it ready for a separate execution step.
Inspect the result
The ticket connects the request and review to the plugin's reported result. A submitted request still needs downstream reconciliation.
This is an illustrative workflow. The product guide uses synthetic transaction data; it does not demonstrate a live bank transaction.
See ticketing with independent approvals and finance control workflows.
Deployment boundary
Map the complete installation
Self-hosting covers the system you operate and the services it calls. A chosen model API, mailbox, or external integration can process data outside your network.
Database and attachments
Choose and operate the database and durable attachment storage for the deployment, including backups and recovery.
Identity and permissions
Connect the supported identity setup and verify who can read tickets, request actions, review them, and execute them.
Models and connected systems
Choose the services used for inference, email, and plugin actions. Include their data handling and network access in your deployment review.
For on-premises or private-cloud deployment, review data flows and operating responsibilities. Include the model endpoint you choose.
Regulated operations
Turn the control requirement into a test
A finance or claims team may need a particular data location, access policy, review step, or evidence record. Name that requirement, then verify it against the deployment and the exact action.
Use the self-hosted ticketing evaluation checklist to record owners, test results, and unresolved requirements.
Operating responsibility
Give the installation an owner
Your team owns patching, backups, restore tests, monitoring, capacity, and access. Your integrations and source changes also need regression checks when the product changes.
Compare Enterprise deployment and support with managed service when deciding who should operate the system.
Evaluation checklist
Keep a requirement, an owner, and a result
Use these checks for one representative workflow. Record who owns each requirement, what the test showed, and what remains unresolved. Start with synthetic data and a test integration before accepting a production workflow.
| Requirement | What to verify | Evidence to keep |
|---|---|---|
| Processing locations | Trace tickets, attachments, identity, email, model requests, integrations, logs, and backups. | A service and data-flow inventory with approved locations. |
| Access and identity | Test who can view the evidence, request the action, review it, and execute it. | Observed results for eligible and ineligible accounts. |
| Customization | Choose configuration, a maintained integration, or a source change for each requirement. | An extension contract, test result, and named maintenance owner. |
| Independent review | Test requester separation, saved fields, rejection, expiry, and changed-ticket behavior. | The request, review decision, and refused execution results. |
| Execution outcome | Test success, failure, and a lost response against a synthetic downstream service. | Reported references, reconciliation steps, and blocked replay evidence. |
| Recovery and upgrades | Restore a backup and rehearse an upgrade with custom integrations enabled. | A restore record, compatibility checks, and an operating owner. |
| Source access and support | Confirm the Enterprise agreement covers the inspection, changes, deployment, and support you need. | Agreed rights and a maintenance plan for modified code. |
Review deployment data flows and operating responsibilities and use the approval acceptance checks for the sensitive action.
Self-hosted ticketing Q&A
Questions to settle before deployment
Agree the workflow, deployment boundary, source-access terms, and operating responsibilities.
What does self-hosted ticketing mean?
Your team operates the application, database, storage, and supporting services in its own environment or private cloud. The deployment still needs a documented plan for identity, email, model endpoints, integrations, backups, and upgrades.
How can we customize Latch?
Start with ticket fields and workflow configuration. Use the API or a plugin for connected actions. Enterprise source access supports inspection and changes allowed by the agreed licence; source changes need their own maintenance and upgrade plan.
Is the source code available?
Source code is available to Enterprise customers under commercial terms. Review the agreement for access, modification, deployment, redistribution, and support rights. Enterprise source access is different from an open-source licence.
Can an action require another person to review it?
Yes. Sensitive plugin actions can require independent review. The action requester cannot approve or execute that same request. Approval and execution are separate steps, and the ticket connects the review to the result reported by the plugin.
Can we use a disconnected network?
Bring the network restriction into the deployment review. Validate installation, identity, storage, mail, model endpoints, connected actions, upgrades, and recovery against the connections your environment permits before relying on a disconnected workflow.
Who operates the installation?
Your team owns infrastructure, access, upgrades, backups, restore testing, monitoring, and incident response. Agree product support and the handling of custom integrations or source changes as part of the Enterprise engagement.
Workflow review
Bring the queue and the control requirement
Follow one request through configuration, independent review, connected action, and the record of its result.
Free workspace · 100 tickets · No card required. See what is included.