Audit log

Every event inside of withHuman is recorded and saved. The audit log is your way of viewing those events. If you ever want to know anything that happened inside of withHuman, you should head to the audit log.

The audit log is part of the hosted edition. The open edition keeps every decision on record but no event stream, so its request pages show the request, its routing, its reviewers and its decision without the timeline described here.

Immutability preserves the resources and revisions those events refer to, so later changes don't erase their history.

Open Audit log in the sidebar. You'll need permission to read your organization's audit log to use this page.

Recorded events

Every action in withHuman produces an event in the audit log. This includes approvals, denials, webhook calls, pipeline evaluations, changes to agents and teams, and more. These are just a few examples of what you can find there.

Each row is an event, which records something that happened. One request can have several events: it arrived, a pipeline checked it, a reviewer claimed it, and someone made a decision. Events also record configuration changes, such as activating an approval pipeline or editing a team's members.

The Audit event types reference explains the event names and the useful details recorded with each one.

Event details

The audit log shows you four things by default.

For example, when the Support assistant submits a refund request, the agent is the actor and the request is the subject. When Chris approves it, Chris is the actor, but the subject is still the same request.

Select a row to open the event. Along with the actor, subject and timestamp, you'll see the event's own ID and its data. The data contains the details recorded for that particular event. A decision event, for example, can show the result and the reviewer's note.

Event filters

Use the filters above the list to narrow down what you're looking for.

Filters work together. Searching for issue_refund with Last 24 hours selected only shows matching events from that period. Select Clear to remove the filters.

The count above the list is the number of events, not the number of requests. The newest events appear first. Select Time to reverse the order, or Event or Actor to sort by those columns. Use Load more to see further results when it's available.

Remember that you're filtering events. Selecting an agent as the Actor shows events that agent caused, but leaves out pipeline activity recorded by System and decisions made by people. Likewise, Approved shows approval events, rather than every event leading up to them.

Request history

Let's follow the Support assistant's $75 refund from the Review queue guide. It went through the agent's approval pipeline, reached the Payments review escalation path, and was approved by Chris.

This request produced eight events. Other requests can have different histories, depending on their pipelines, reviewers and outcome.

flowchart TD
    created["Request received<br/><code>approval.created</code>"] --> started["Pipeline evaluation started<br/><code>request_approval_pipeline.started</code>"]
    started --> block["Refund rule checked<br/><code>request_approval_block.evaluated</code>"]
    block --> completed["Human review needed<br/><code>request_approval_pipeline.completed</code>"]
    completed --> routed["Payments review selected<br/><code>routing.evaluated</code>"]
    routed --> level["Reviewer stage reached<br/><code>routing.level_entered</code>"]
    level --> claimed["Chris claimed the request<br/><code>routing.claimed</code>"]
    claimed --> decided["Chris approved the refund<br/><code>approval.decided</code>"]

Events for a request

Start in Audit log and enter the request ID in Search. If you don't have the ID, search for the tool name, issue_refund, and narrow the Time window to when the request was made.

Open a matching event and check its Subject. You can follow that link to the request to confirm you've found the right one. A tool name can match several requests, so check the amount, agent and other request details before continuing.

On the event page, select All events for this subject. This replaces your filters with the subject's type and ID, bringing the request's history together across all actors and outcomes. Select Time to put the oldest event first.

Reasons for human review

Start with approval.created to see which agent submitted the request. Its data includes the instance ID, tool name and deadline.

Next, open request_approval_block.evaluated. For this refund, three fields explain what happened.

Back in the history, request_approval_pipeline.completed records the pipeline's overall outcome. routing.evaluated shows the selected path, and routing.level_entered records the reviewer stage it reached. Finally, routing.claimed shows when Chris picked up the request.

Decision details

Open approval.decided. The Actor is Chris Battarbee, and Occurred shows when he made the decision. In data, status is approved and note contains Approved. Refund the duplicate $75 charge.

An automatic decision also produces approval.decided, but its actor is System and its data identifies the pipeline as the source. Requests that expire or are withdrawn instead end with approval.expired or approval.cancelled.

This confirms that Chris approved the action. Select Subject to open the related request, or copy the event page's URL to share what you found with someone who has access to your organization's audit log.