Account events provide visibility into customer and administrator activity across your Strivacity instance.
From here, you can review detailed flow-level events, track outgoing notifications, and filter activity for troubleshooting, analytics, or compliance needs.

This section contains two tabs:

• Account events: Detailed, step-by-step breakdowns of customer and administrative journeys.
• Notification history: A consolidated list of notifications sent from your instance.

Account events tab

The Account events tab lists flow-level events generated during customer or administrative sessions. Each event includes high-level attributes (flow type, application, participant) and a detailed breakdown of every step that occurred in the journey.

An account event is composed of the following elements:

• Labels that indicate the outcome of customer journey points.
• Phases that tell you what has happened during a customer's session.
• Blocks that let you know what went down on the application's side.

Labels

When a customer has passed through each journey point, labels are given. The labels are either green for pass or red for fail.

Phases

Phases are activities initiated by the customer or the system. A phase starts and finishes, and contains blocks and API calls. You will see the start of the phase and the result of the phase on the same line.

A flow is a string of phases that happen within each other.

Blocks

Blocks and API calls/responses make up the contents of a phase. Blocks represent what is happening with the application you created. The blocks talk with the APIs to decide the outcome of the phase. You will see the action and the outcome of each block on the same line.

Account event entries

Each row in the Account events tab represents a notification sent from Strivacity. For every entry, the following details are displayed:

• Date: The timestamp indicating when the event occurred.
• Event type: The category of the flow, such as Customer flow or Admin flow.
• Application: The application associated with the event.
• Account: The username or email of the account involved in the event. If the account is unknown or the flow did not involve an authenticated user, this field shows unknown.
• Result: A visual summary of journey outcomes represented by colored labels (green for successful outcomes, red for errors or failures). Selecting the dropdown arrow expands the list to show the specific journey steps that contributed to the result (for example, Identification, Password authentication, Login).
• Actions: Select View event from the kebab menu to open the full event details.

Filtering

The Account events tab includes filtering capabilities that allow administrators to quickly locate specific events based on various criteria.

The following filters are always visible by default:

• Identity store: Filter events by the identity store associated with the account activity.
• Account: Search for events tied to a specific account. You can narrow your search results by username, ID, or email address.

Additional filters can be enabled as needed. These include:

• Application: Narrow events by selecting from the available applications.
• Variants: Apply filters in the context of A/B testing to focus on specific journey variations.
• Label: Labels are assigned to account events based on the outcomes at various journey points. Green labels indicate successful completion, while red labels signify failure. These labels can be used to filter specific account events.
  • For example: flow abandoned, account activation, account impersonation, account linking, account lockout, adaptive access: step-up, adaptive access: step-down, etc.
• Date: Select a date range for events. The following options are available:
  • In the last: Show events that occurred within a specified number of hours or days (for example, "in the last 3 days").
  • In the next: Show events scheduled to occur in the future.
  • More than: Show events that occurred more than a specified time ago.
  • Before: Show events that occurred before a specified absolute date and time.
  • After: Show events that occurred after a specified absolute date and time.
  • Between: Show events between two points in time. You can mix relative and absolute values, such as from -P2W to an exact date.
• Customer IP: Search for events using the customer's IP address.

📘

When you apply filters, the URL automatically updates to reflect your filter selection. This allows you to share or bookmark your current view. Your last-used filters are remembered: if you navigate away and return, the same filters will be applied.

📘

If you navigate to Account events from a dashboard widget (for example, selecting a login success count), the page automatically opens with the same filters applied. This lets you move directly from high-level metrics to the underlying account events that match.

Account event details

Selecting any row in the Account events table opens a detailed view of that individual event. This view provides a full breakdown of what occurred during the customer's session or administrative action, including the steps, blocks, API calls, and outcomes that make up the event.

Header

The header displays high-level information about the event:

• Flow participant: The identity involved in the event. When an action is performed on behalf of another user, both identities are shown.
• Application: The application associated with the flow.
• Flow started: When the event began.
• Flow type: Indicates whether the flow was a Customer flow or an Administrative flow.
• Event ID: A unique identifier for the event. One or more labels, such as Flow abandoned or Registration, may appear alongside the ID to indicate the type or outcome of the flow.
• Original login: Links the event to the originating login session, when available.
• Show event hook logs: If event hooks were triggered, a link appears to view their logs.
• Advanced view toggle: Allows switching between simplified and more detailed technical breakdown.

Timeline and phases

Below the header, the event is displayed as a timestamped timeline. Each timestamp marks the beginning of a new phase or step in the flow.

Phases and steps show:

• Phase name (for example, “Initializing”, “Identification started”, “Fast path assessments”)
• Context (for example, “Registration”, “Personal account flow started”)
• Whether additional detail is available (expandable section). Opening a phase reveals the internal actions that occurred within it.

Blocks and decisions

Within each expanded phase, you will see blocks, which represent evaluations or decisions made by the system.

These include:

• Loading or evaluating session data
• Fast-path or risk assessments
• Device, organization, or identity evaluations
• Registration/login path decisions

Each block displays:

• Block name
• Outcome (for example, Success, Display, None selected, Pre-fill, or Login)

Blocks map directly to the logical steps of the customer journey.

Phone risk outcomes

When a journey includes phone-based identity verification, some blocks may display additional phone risk evaluation data. These values reflect details returned by the phone risk provider and help fraud teams review SIM-swap indicators and line-type characteristics.

SIM-swap indicators may include:

{
  "simChangeDate": "2021-02-03T00:00:00Z",
  "callForwardingEnabled": "10",
  "changeDetected": "Y"
}

Line-type detection may include:

{
  "serviceProvider": "XYZ",
  "serviceType": "Mobile",
  "countryCode": "XY"
}

Adaptive MFA outcomes

When adaptive rules or "After identity verification" hooks influence multi-factor authentication requirements, account events include additional details within the relevant block. These values help administrators understand why a customer was required to perform step-up authentication, allowed to step down, or blocked from continuing.

Labels may include:

• failure:blocked_connection: the session was rejected based on adaptive signals.
• step-up: the user was required to complete additional authentication.
• step-down: the user was allowed to skip certain MFA authenticators.

Triggering signals (when available) appear as metadata inside the block. Examples include:

• IP address: the evaluated customer IP
• Location: resolved city, region, and country
• Anonymous network: whether the IP was associated with an anonymizing service
• Bot detection: risk level returned by bot assessment
• Improbable travel: whether location velocity indicated high risk
• Device recognition: whether the device was recognized or trusted
• Behavior analysis: time- or location-based anomalies

These details appear inside the expanded block view for both adaptive rule evaluations and "After identity verification" hook decisions.

Document verification outcomes

When a journey includes physical document verification, account events display additional details that explain why a transaction succeeded or failed. These values appear inside the expanded block view and help administrators understand the verification result and contributing factors.

Decision outputs are grouped into three levels:

Level 1 - segment/action codes: high-level conclusions returned by the verification provider.

Examples include:

• Unsupported ID
• Submission error
• Re-capture required
• Expired IDFraud detected
• Verified

Level 2 - high-level conclusions: identifies which analysis category contributed to the Level 1 result.

Examples include:

• Text analysis
• Behavior analysis
• Visual analysis
• Expired ID
• Unsupported ID
• Submission error
• Capture quality

Level 3 - detailed conclusions: provides additional classification and document-specific details.

Examples include:

• Document class and document name
• Issuer code, issuer name
• Issuer country (2-digit, 3-digit, and continent)
• Document series information
• Information flags returned by the verification provider

These values appear only when physical document verification is invoked during the journey and reflect the exact data returned by the verification service.

External login provider metadata

When customers authenticate with an external identity provider (for example, Microsoft or Google), Strivacity records information returned in the provider’s tokens or assertions. This information is displayed under the External login provider assessment block during the Identification phase.

What is shown depends on the Only store mapped values setting in the External login provider configuration:

• Enabled: Only mapped attributes (such as email) are recorded.
• Disabled: The full metadata returned by the identity provider is recorded, for example, attributes such as userPrincipalName, mail, givenName, or surname.

This data helps troubleshoot claim-mapping or account-linking issues by showing what information Strivacity received from the provider.

Example:

"identities": {
  "microsoft": {
    "id": "microsoft|a12b34c56d7890ef",
    "display": "[email protected]",
    "metadata": {
      "userPrincipalName": "[email protected]",
      "mail": "[email protected]",
      "displayName": "Natalie Estevez",
      "givenName": "Natalie",
      "surname": "Estevez"
    }
  }
}

API calls and responses

Many phases also include the backend API activity associated with the event.

These can appear in either order:

• Call: The outbound request sent by Strivacity (for example, POST /token, GET /login, POST /init).
• Response: The response returned by the service or identity provider.

This information helps administrators understand the underlying cause of a failure or unexpected behavior without exposing sensitive internal system details.

📘

Strivacity will store up to 30 days of account events by default. Additional storage durations are available on request.

Notification history tab

The Notification history tab provides a consolidated view of all notifications that have been sent out across your instance. This tab is especially useful for administrators looking to track outgoing communication for troubleshooting or auditing purposes.

Notification entries

Each row in the Notification history tab represents a notification sent from Strivacity. For every entry, the following details are displayed:

• Date: When the notification was sent.
• Target: The recipient's identifier, such as an email address or phone number.
• Notification template, policy: The name of the notification template used and the associated policy.
• Expiration time: If applicable, the date and time when the notification or its associated action expires.
• Notification content: Select the kebab menu (︙) at the end of the row, then choose View notification to see the notification’s content. Sensitive data (such as OTP codes or magic links) is never displayed.

Filtering

The Notification history tab includes filtering capabilities that allow administrators to quickly locate specific notifications based on various criteria.

The following filter is always visible by default:

• Target: Filter notifications by the recipient’s email address or phone number.

Additional filters can be enabled as needed. These include:

• Account event ID: Filter notifications associated with a specific account event.
• Account ID: Show notifications related to a specific customer account.
• Invitation ID: Filter notifications related to a specific invitation.
• Identity store: Narrow results by the identity store associated with the notification.

📘

When you apply filters, the URL automatically updates to reflect your filter selection. This allows you to share or bookmark your current view. Your last-used filters are remembered: if you navigate away and return, the same filters will be applied.

Notification details

Selecting a notification from the Notification history tab opens a detailed view showing the full context of the notification that was sent. This view helps administrators audit communication sent to customers and verify delivery details.

Header

The header displays high-level information about the event:

• Date: When the notification was sent.
• Target: Where the notification was delivered (for example, an email address or phone number).
• Channel: The delivery channel used (for example, EMAIL or SMS).
• Expiration time: If applicable, when the notification or its associated action expires.
• Account: The customer account associated with the notification.
• Identity store: The identity store where the account resides.
• Notification template: The template used to generate the notification.
• Notification policy: The policy governing how and when the notification was sent.
• Account event ID: The account event that triggered the notification.

📘

Some fields in the header include quick actions such as opening the related resource (for example, Go to account, Go to notification template) or copying identifiers (such as the account ID, policy ID, or account event ID). Available actions vary by field and appear when selecting the arrow next to the field value.

Notification content

Below the header, the body of the notification shows the rendered message content sent to the recipient. Sensitive or high-risk values (such as one-time passcodes and magic-link URLs). are intentionally omitted for security reasons.