Skip to main content
Version: 11.3.0

Activity Log

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

The Activity Log table in Control Center, accessed via the HYPR Affirm menu's Activity Log tab. 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 Outcome Status Enum. See the enum reference for the complete value set and what each value means.
Workflow IDThe Verification Flow ID — 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 (typically email 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 Outcome Status Enum. Decision values are displayed as colored badges (green for successful verification, red for failure) and stay consistent across the table, API, and event stream.
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.

Each row is clickable — selecting a row opens the per-flow detail view described below. The bottom of the table shows pagination controls (range, page selector, page-size selector).

Activity Log details view​

Clicking a row opens that verification's detail page — a single screen that brings together everything captured about the run.

The detail-view header — a summary grid covering the verification's headline values. The Decision badge in the upper right matches the colour-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 — the verification's headline values laid out as a fixed grid: who, when, how long, which workflow, the final decision, and the correlation identifiers (Verification Flow ID and the Workflow Code shown to the requester). Identifiers are copy-able directly from the grid, so an analyst can paste them into the API, the Audit Trail, or a support ticket.
  • A per-step result list below — 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.

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 summarising 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.

Only steps that this workflow included appear in the result list — there is no noise from steps the flow didn't run. The detail page reflects exactly what the requester went through, in the order they went through it. See Observability and Verification Flow 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).

A Document and Biometric Verification step expanded on a successful verification — Document Report with per-check 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​

Per-step PASS / FAIL outcomes, retry-attempt counters, and the per-check status indicators displayed in the expanded card are written by the Risk Policy Builder at runtime. The Policy Evaluation Kit assigned to the workflow walks 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 the rule-authoring side — predicates, operators, Fail-rule outcomes (Deny / Escalate immediately / Continue on failure / Redirect immediately) — see the Risk Policy Builder reference.