Follow the request, approval, and action result on the ticket
A later reviewer needs to know what was requested, who reviewed it, and what happened afterward. Latch connects ticket activity, saved action requests, approval decisions, and plugin execution records so the review starts from the work itself.
Use that history to inspect a case, then apply the access and preservation controls your organisation requires around the records.
Ask a different question at each step
In the illustrative transaction-reprocess workflow, Maya submits an action and Daniel reviews it. Their decision and the later execution answer related questions, but neither substitutes for the other.
What was submitted?
The action request identifies the requester, action, request time, and saved form inputs. The review dialog shows those submitted values beside the ticket's supporting evidence. Execution uses those inputs with current case context.
Who reviewed it?
The approval request retains its reviewer decision. A rejection can include an optional reason saved on the request. Maker-checker blocks the requester from reviewing their own request; another eligible operator must decide.
What was attempted?
An approved request still has to be executed. Its linked execution record supplies the attempt and reported result. The reviewer may also execute if eligible, so the sequence does not necessarily involve a third person.
What result can be established?
The plugin response shows what the connected system reported. A lost response or unsuccessful attempt can leave the external outcome uncertain. Check the target system as well as the local record before deciding how to recover.
The ticketing workflow with approvals connects these steps. Read the approval lifecycle for expiry, ticket-change invalidation, and execution checks, or the plugin action logging guide when defining the evidence your connected operation needs.
Find the requests behind the report
The Approval audit report groups requests by status, action, requester, reviewer, plugin, or time. Open the linked tickets to inspect the case evidence, and export the selected report to PDF or Excel.
Its date window selects requests by when they were requested. A request submitted earlier and approved this week does not automatically belong to this week's request cohort. The summary groups approved and executed requests together; use the status breakdown and execution record when counting completed operations.
The screenshot guide explains the report with illustrative data. Finance controls applies the same record to a review of consequential operations.
An application history needs preservation controls
Latch adds events as work occurs. Its append-only application record helps operators follow changes and decisions over time. That does not make the underlying database independently sealed: a privileged database operator can affect records outside the normal application path.
For independent preservation, define who can administer the database, what is exported, how copies are protected, and how retention or legal hold is enforced. WORM storage, cryptographic sealing, and a legal archive are separate requirements to establish in the surrounding system.
Locate each kind of evidence
The request and approval lifecycle have their own records, and execution has a linked record. An access denial may also be captured in operational security logs. A blocked HTTP request is not automatically a visible event in the ticket timeline.
Test the particular denial or review path you need to evidence. Confirm the actor, reason, request reference, and location of the resulting record. The approval evidence guide explains the questions a review should answer.
Operate the records in your chosen deployment
In a customer-deployed installation, your team operates the application database and its backup and retention policies. Plugins and model services can send data to their configured destinations, so review those connections along with the storage location and administrator access.
See self-hosted ticketing and the security and deployment guide for the operating responsibilities. Source-code access on Enterprise supports inspection under the agreed commercial licence. Record ownership and preservation controls still need to be evaluated separately.
Choose the deployment and control detail you need
Start with self-hosted ticketing or the complete approval workflow. The feature pages explain how independent review, action records and deployment controls fit together.
Evaluate your infrastructure, operating responsibilities and customization path.
Keep the incoming ticket, independent review and external result together.
Prevent the action requester from approving or executing their own request.
See configured action gates, request states and separate execution checks.
Inspect identity, storage, integration traffic and operational responsibilities.
Bring email, forms and API requests into one ticket queue.
Apply ticket records, checklist reviews and configured approval actions to claims work.
Questions about history and evidence
Establish what the application records and what your preservation policy requires.
What can a reviewer inspect?
The ticket context, activity, action requests, reviewer decisions, and linked plugin execution records. Approval review shows the saved submitted fields. The execution record shows the outcome reported by the plugin, which may still need reconciliation with the connected system.
Does approval prove the external operation completed?
No. Approval records a decision about the request. Execution is a separate step with its own result. A timeout or other unsuccessful response can leave the external outcome uncertain; inspect the execution record and the connected system before authorizing another operation.
Is the audit history independently immutable?
Latch adds events to its application audit history as work occurs. This append-only application record is not independently sealed or WORM storage. Privileged database operators can affect the underlying records. Apply the access, backup, retention, legal-hold, and independent preservation controls your requirements call for.
Does every blocked attempt appear on the ticket timeline?
The request and approval lifecycle have their own history, and plugin execution has a linked record. Access denials can also appear in operational security logs. Do not assume that every denied HTTP request is a ticket activity event; inspect the relevant record for the specific control you are evaluating.
Where are the records stored?
In the application database for your deployment. In a customer-deployed installation your team operates that database and its backups. Configured plugins and model services may process data outside it, so the deployment and connection choices remain part of the data-flow review.
What can the approval report export?
Approval reports support PDF and Excel exports with links to case evidence. The date window selects requests by when they were requested. Use the status breakdown and execution record to distinguish approvals from completed external actions.
Does the history establish compliance?
It supplies an operating record for review. Your team still defines the control requirements, checks the evidence, and establishes its retention and preservation policies. A product audit history alone is not a regulatory certification or a legal archive.
Inspect the request, decision, and reported result
Use the illustrated approval guide to follow a request through review and separate execution, then inspect the report that links back to the case.
Free workspace · 100 tickets · No card required. See what is included.