Skip to main content
Version: 11.3.0

Activity Log

The Activity Log records every verification attempt against the tenant, whether completed, abandoned or denied, with the per-flow status, the decision and a link to a detail view for each row. Use the date selection field and the search bar to filter entries.

Activity Log tab with search and date range filters above a table of verification attempts showing Verified and Unverified decisions

The Activity Log table in Control Center, opened from the Activity Log tab of the HYPR Affirm menu. Each row is a verification attempt with its Status, Workflow ID, Date & Time, Requester, Reviewer, Decision, Source and Initiated By.

Activity Log Fields​

The Activity Log table uses the following columns:

FieldDescription
StatusThe verification's lifecycle state, drawn from the canonical Verification Status Values. See that page for the complete value set and what each value means.
Workflow IDThe ID of this verification attempt. It is the correlation key that ties this row to the Audit Trail, the Affirm API and the per-flow event stream. A copy icon next to the value copies the full ID.
Date & TimeThe start time of the verification, with date and 12-hour time.
RequesterThe requester's identifier, for example an email address or UPN.
ReviewerThe user who reviewed the verification. If automated approval was used, the Reviewer is HYPR.
DecisionThe verification's final decision, also drawn from the canonical Verification Status Values. The decision is displayed as a badge: Verified in green, or Unverified in red (gray while the verification is In Progress or Not Started). The workflow API reports its own result values rather than these labels; see that page for both.
SourceThe system surface that originated the verification (for example, Client for a self-service browser flow).
Initiated ByThe user or system that initiated the verification. For Helpdesk-initiated flows this is the Helpdesk agent's identity; for self-service flows it is System or the originating system identifier.

Click a row to open its detail view, described in the following section. The bottom of the table shows pagination controls (range, page selector, page-size selector).

Activity Log Details View​

The detail page brings together everything captured about one verification on a single screen.

Activity Log detail view summary grid with Workflow ID, Workflow Code, start and end times, duration, Completed status and a Verified decision badge

The detail-view header: a summary grid covering the verification's headline values. The Decision badge in the upper right matches the color-coded value from the table.

The detail page serves the use cases the Activity Log table can't: investigating a single verification end to end, correlating it with downstream systems, reproducing what the requester experienced and producing evidence for audit or compliance review.

It groups information into two regions:

  • A summary grid at the top, with the verification's headline values laid out as a fixed grid: who, when, how long, which workflow, the final decision and the correlation identifiers (Workflow ID and the Workflow Code shown to the requester). You can copy identifiers directly from the grid and paste them into the API, the Audit Trail or a support ticket.
  • A per-step result list under the grid, with one expandable card per verification step that actually ran in this flow. Each card shows the step's start, end, duration and a status indicator with a result counter.
Per-step result list with step cards grouped under Unverified and Verified/Completed, each with a result counter, and an Outcome Result card

The per-step result list groups step cards by overall status: an Unverified section for steps that produced a failure verdict, a Verified/Completed section for steps that passed, and an Outcome Result card at the bottom summarizing the workflow's overall outcome. Each step card carries a result counter, for example 3 Failed or 18 Verified, drawn from the policy ledger entries the Risk Policy Builder appended during the verification.

The detail page reflects exactly what the requester went through, in the order they went through it. See Observability and the Workflow ID for how the detail view fits into the broader correlation model.

Expanding a step card surfaces the named individual checks that ran for that step, each with its own pass/fail status, grouped into reports (Document Report, Watchlist Standard Report, Motion Report, Photo Fully Auto Report).

Expanded Document and Biometric Verification step card showing 18 Verified and Document Report checks such as First Name Match, each Verified

A Document and Biometric Verification step expanded on a successful verification — Document Report with per-check rows.

Expanded Document and Biometric Verification step card showing 3 Failed, Overall Result Unverified and failing Motion Report rows

The same step expanded on an unverified verification — Overall Result: Unverified followed by the Motion Report rows that contributed to the failure.

Where Step Outcomes Come From​

The Risk Policy Builder writes the per-step PASS / FAIL outcomes, retry-attempt counters and per-check status indicators shown in the expanded card at runtime. The Policy Evaluation Kit assigned to the workflow evaluates its predicate-driven rules against each step's emitted risk signals and writes one ledger entry per evaluation. The Activity Log detail view renders those ledger entries as the step cards, the per-check status rows and the report-grouped breakdowns. For rule authoring, including predicates, operators and Fail-rule outcomes (Deny / Escalate immediately / Continue on failure / Redirect immediately), see the Risk Policy Builder reference.