Self-Hosted Ticketing Evaluation Checklist

A ticketing system can run on your server and still send attachments, model requests or operational logs to another service. It can expose source code without giving your team the rights it needs to maintain a modified version. A deployment label does not answer either question.

Evaluate one workflow and the installation around it. Keep a requirement, an owner and an observed result for each control. The worksheet below works for any shortlisted self-hosted help desk; the Latch examples identify product mechanics to inspect, not a completed security or compliance assessment.

1. Name the records and the operating requirement

Choose a representative request. A payment exception might include an account reference, an attachment, an operator's reason and a proposed reprocess action. Record which people and systems need each item, where it may be processed and who owns the requirement.

Distinguish an agreed customer requirement from an internal preference or a question awaiting review. Regulated teams may have additional access, retention and evidence requirements, but installing software on their own infrastructure does not establish compliance.

For the evaluation, write down:

• The workflow and the synthetic records used in the test.
• The allowed processing and backup locations.
• The identities allowed to view, request, review and execute.
• The downstream system that carries out the operation.
• The person who can accept each result or resolve an unanswered question.

2. Trace every data path

Map the application, database, attachment storage, identity service, mail, AI endpoints, integrations, logs, backups and support access. Include services reached under your own API keys: customer-managed credentials do not make a commercial service local.

Use this component matrix before evaluating the product's deployment diagram. Add a row for every separate destination.

For Latch's deployment options, request the supported release, storage design and identity configuration. Verify encrypted storage and transport in the actual installation, including its keys and certificate ownership. A diagram alone does not establish the running settings.

3. Separate configuration, integration and source changes

Ask the workflow owner to change one field definition, the developer to demonstrate one connected action, and the product owner to classify a requirement beyond the existing extension points.

In Latch, tag fields and workflow settings address some configuration needs. Plugins and APIs connect actions to other systems. Enterprise source access is a separate commercial option for inspection and changes allowed by the agreement.

Request the source agreement before assuming modification, redistribution, continuing-use or fork rights. Also ask which releases are delivered, how modified installations receive fixes and who handles merge and regression work. The configuration/plugin/source decision table helps assign those responsibilities.

4. Test identity and review at the action boundary

Use separate synthetic requester and reviewer accounts. Test an ineligible account too. Verify current access after disabling or changing an identity, including session/token behavior; do not infer immediate revocation from the presence of OIDC sign-in.

For a Latch maker-checker action, the action requester cannot approve, reject or execute that same request. Another eligible operator reviews it, and approval is separate from execution. The reviewer may also execute if permitted. Requirements for a third person, several sequential approvers or a quorum need separate evaluation.

Inspect the saved submitted values, request lifetime and ticket-change invalidation setting. Then change permissions or action availability after approval and test execution again. The approval acceptance checklist lists useful expected outcomes.

An amount threshold belongs in connected business logic; the current Latch gate editor does not provide a monetary rule builder. Ask the integration owner to demonstrate that condition with the same synthetic records.

5. Inspect a success and an uncertain result

Run the test action against a test service that returns a known reference. Compare the request, reviewer identity, execution attempt, response and any applied ticket effects. Keep the evidence artifact rather than writing only “passed.”

Next, simulate a lost response after the test service receives the operation. Latch retains uncertain approved execution attempts and does not automatically replay them. The integration owner must establish the external result and which local effects completed before authorizing further work.

The following example is an illustrative acceptance record, not an observed deployment result:

The approval feature guide contains synthetic product screenshots. Those show the interface, not a real payment result. Application history and exports also do not establish independent WORM retention or legal evidentiary guarantees.

6. Rehearse recovery and an upgrade

Restore a synthetic ticket and its attachment from backup into a separate test environment. Verify access, history and the attachment after recovery. Then upgrade the test installation with the integration enabled and run the workflow again.

Record the application, database and integration versions, migration steps, elapsed recovery time and any missing records. Check whether the recovery meets your agreed objective. Switching an application image back does not necessarily reverse database migrations.

Name owners for patching, backups, restore testing, credential rotation and support. A source-access agreement and a support contract should explain what happens when application modifications or custom integrations are involved.

7. Verify restricted networks with the full workflow

If a disconnected deployment is required, test it under that restriction. Include installation artifacts, identity, mail, inference, plugins, upgrades and recovery. Document every imported artifact and approved connection rather than assuming a local database proves offline operation.

Latch integration destinations must fit its provider network policy. Loopback, Tailscale services and metadata endpoints are denied; private endpoints need a supported operator-controlled mapping. Review the deployment boundary with the installation owner before designing the connection. Do not assume any internal URL is allowed.

Copy this acceptance worksheet

Use one row per requirement. Replace “To complete” with an artifact reference and observed result, or leave the item unresolved. Add an acceptance date only when the responsible owner has reviewed the evidence.

A useful evaluation can end with open items. A failed test identifies work to resolve; an untested claim stays unaccepted. That gives the purchase decision a clear basis without turning a checklist into a certificate.

See the Latch product workflow, then bring one workflow and your evidence requirements to a deployment review.