A vendor bank-detail change arrives by email. The operator needs supporting evidence, a second person's review and an update in the finance system. Adding a text field solves the first part. It does not connect the finance system or define who may run the update.
Customizable ticketing starts with choosing the right place for each change. Some requirements belong in configuration. Others need a plugin action or a change to the application itself. Those choices carry different maintenance costs.
Choose the smallest change that meets the requirement
Start with the information the operator needs, the action another system must perform and the control that should surround it. Then choose the extension method.
| Requirement | Start with | Example | Who maintains it? |
|---|---|---|---|
| Capture different evidence | Product configuration | A tag and its fields capture the vendor reference, proposed change and review evidence. | The workflow owner maintains field definitions and reporting choices. |
| Perform an operation in another system | A plugin or documented API integration | A customer-built action calls the finance service and returns its result to the ticket. | Engineering maintains the integration, credentials, business rules and downstream behavior. |
| Change behavior beyond supported configuration and extension points | Enterprise source access under agreed terms | A proposed specialized screen or interaction changes the application. | Confirm modification rights, compatibility and support; assign an owner for testing, upgrades and merge work. |
Use configuration where it answers the requirement. Write an integration where another system must act. Evaluate a source change when neither supported path fits.
Latch offers source code on Enterprise. That is a commercial source-access offer. The agreement determines inspection, modification, deployment and redistribution rights; code visibility alone does not establish an unrestricted open-source licence.
Follow one vendor change through the ticket
The following is an illustrative design, not a claim that Latch ships a maintained connector for your finance system.
An operator records the vendor reference, attaches the request and checks the evidence. A customer-built plugin exposes a Request bank-detail update action with a form for the proposed values and reason. Latch stores the submitted action fields when the operator requests review.
The administrator configures maker-checker for that action. Another eligible operator reviews the saved fields and approves or rejects the request. Approval and execution are separate steps; an eligible reviewer may also execute, but the action requester cannot approve, reject or execute that same request.
On execution, Latch checks the applicable permissions and current action availability again. The plugin validates the business request, calls the finance service and returns the reported outcome. Supported responses can add a comment or request a valid ticket status change, keeping the result beside the work.
The checklist is configuration. The finance connection is an integration. A new bespoke screen would be an application change. The team can evaluate each without treating every requirement as a reason to fork the product.
Keep platform controls and business rules explicit
Latch's current approval controls provide a default plugin gate and per-action overrides: no gate or maker-checker. Administrators also configure request expiry and whether ticket changes invalidate an open request before execution.
An amount condition, a vendor verification rule or a customer-tier decision belongs in the connected business logic. The current gate editor is not an arbitrary monetary rule builder, sequential approval chain or quorum engine. A plugin designer must explain how those business rules affect action availability and validation.
The platform keeps the requester/reviewer boundary, permission checks and approval lifecycle around the action. The integration still owns its downstream permissions, input validation and behavior when the external system fails.
Design the unsuccessful path before the first release
A finance service may accept an update and then lose the response. Retrying immediately can apply another operation without resolving what the first one did.
Latch retains executing or uncertain approval attempts for investigation. It does not automatically replay an uncertain approved action. The integration owner must reconcile the provider's authoritative result and any local effects before separately authorizing further work.
For the example, ask the developer to demonstrate:
- A missing vendor reference makes the action unavailable or fails validation before the update.
- The action requester cannot provide their own independent review.
- A rejected request does not run the finance operation.
- An expired or invalidated request requires fresh review before execution.
- A lost response leaves enough evidence to investigate without blindly submitting another update.
These are acceptance tests for the proposed integration. They are not proof that a connector has already passed them.
Deployment and customization have separate owners
Self-hosted ticketing gives a team responsibility for its installation, upgrade schedule, backups and network configuration. A plugin adds another service to that operating plan. Source modifications add compatibility and regression work.
Document the plugin's version, endpoint, allowed connections, secret rotation, timeout behavior and support owner. Private integration endpoints must fit the installation's network policy; a service running on the same machine is not automatically an allowed destination.
Before upgrading, run the synthetic workflow against the new application and plugin versions. Check the fields, action discovery, review, returned result and failure evidence. A successful health request alone does not demonstrate the business flow.
Bring one requirement to the product review
Describe the incoming request, the evidence it needs and the system that must act. Identify which changes are configuration, integration or source work, and who will maintain each.
See Latch's ticketing workflow, then use the deployment evaluation checklist to record the evidence you need. The developer overview explains the API and SDK path for a custom action.