> ## Documentation Index
> Fetch the complete documentation index at: https://developers.argosidentity.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Session Journey

> Trace the entire path a single submission takes through the live form in chronological order, and learn how to interpret why a user encountered a specific outcome or error.

## What is Session Journey

Session Journey is a dashboard feature that **gathers every event that occurred from the moment a user entered the live form until the final outcome (approved, rejected, or pending), grouped chronologically as a single submission unit**.

Each event is collected from both the frontend (behavior observed on the user's screen) and the backend (verifications and decisions executed on the server). This lets you trace back "**why** this user was blocked at this step" and "what the rejection or pending reason was."

<Info>
  Unlike the [Event Log](/dashboard/en/event), which tracks admin activity and deletion history, Session Journey focuses on **the verification progress of a single submission**.
</Info>

## Session status

In the Session Journey list, each submission shows its progress at a glance through its **session status**. This status is a different value from the final KYC decision (approved, rejected, or pending); it indicates how far the journey has progressed.

| Status        | Meaning                                                                                                  |
| ------------- | -------------------------------------------------------------------------------------------------------- |
| `IN_PROGRESS` | In progress — has not yet reached a final outcome                                                        |
| `COMPLETED`   | Completed — the user finished the journey to the end (the outcome may be approved, rejected, or pending) |
| `DROPPED`     | Dropped off — the user left without completing (did not reach the final outcome page)                    |
| `ERROR`       | Error — left the normal flow, e.g., via an error page                                                    |

<Note>
  `COMPLETED` only means "the journey was completed to the end"; it does not mean "approved." Always confirm the final approved, rejected, or pending status with the BE decision events (`APPROVED`, `REJECTED`, `PENDING`).
</Note>

## Key cautions when interpreting

<Warning>
  **Events are listed chronologically, but in reality many verifications run concurrently.**

  Just because events appear top to bottom on the screen does not mean "the earlier event caused the later one." For example, ID document recognition, liveness, and age verification run almost simultaneously, and the display order merely reflects minute differences in when each was recorded. **Judge causality from each event's result value and user impact, not from the order.**
</Warning>

## Frontend (FE) and backend (BE) events

Session Journey events fall into two types depending on their source.

| Source            | Meaning                                                                | Examples                                                           |
| ----------------- | ---------------------------------------------------------------------- | ------------------------------------------------------------------ |
| **FE (frontend)** | Observed signals about the screens and actions the user saw            | Screen entry, camera activation, error page entry                  |
| **BE (backend)**  | Actual verification, decision, and finalization executed on the server | ID document recognition, face comparison, final approval/rejection |

<Note>
  **The actual basis for blocking or rejection is always BE events.** FE events (e.g., `ERROR_PAGE_VIEWED`, `FINAL_PAGE_VIEW`) are merely observations that the user reached that screen; the final outcome must be confirmed with the BE decision events (`APPROVED`, `REJECTED`, `PENDING`) of the same submission.

  FE and BE sometimes record the same action as a pair. For example: `FRONT_SESSION_START` (FE) ↔ `SESSION_CREATED` (BE), `CREATE_FLOW` (an API call from an FE screen) ↔ `FLOW_ID_ISSUED` (BE processing result). FE shows "what the screen did," while BE shows "how the server decided."
</Note>

## Stages of the journey

The Session Journey broadly flows through three segments: **Pre-checks → Main → Post**.

<Steps>
  <Step title="Pre-checks — Entry and policy checks">
    The gating (Guard) stage before the main verification, including session creation and token, duplicate, IP, and device checks. If a user is stopped in this segment, they cannot enter ID document capture and are blocked (BLOCKED).
  </Step>

  <Step title="STEP1 — ID document verification">
    ID document-related verifications run simultaneously, including document capture, OCR recognition, liveness, age, expiration, and blacklist checks. On success, a submission (Submission) is created.
  </Step>

  <Step title="Pre-STEP2 — Account verification (optional)">
    Occurs only in projects that require account-based verification, such as 1-won transfers or account holder name lookups.
  </Step>

  <Step title="STEP2 — Selfie/face verification">
    Face-related verifications run simultaneously, including selfie liveness, face comparison, duplicate, government authenticity checks, and custom policies.
  </Step>

  <Step title="Final decision and notification">
    All verification results are aggregated to finalize the submission as approved, rejected, or pending, and the result is notified via webhook and email.
  </Step>

  <Step title="Post — Result page">
    The user reaches the result page and the journey ends.
  </Step>
</Steps>

## The three final decisions

When the Main segment ends, the submission is always finalized as one of the following three.

<CardGroup cols={3}>
  <Card title="APPROVED" icon="circle-check">
    Passed all verifications and was automatically approved. No separate reason.
  </Card>

  <Card title="REJECTED" icon="circle-xmark">
    Rejected due to verification/policy failure or exceeding the retry limit. The reason is distinguished by the `reason` value.
  </Card>

  <Card title="PENDING" icon="circle-pause">
    Automatic judgment is held and manual review is required. The reason is distinguished by the `reason` value.
  </Card>
</CardGroup>

For the specific reason codes of rejection and pending, see the "Final decision reasons" table in the [Session Journey event reference](/dashboard/en/session-journey/event-reference).

## Interpreting error causes

Each event shows a **User impact**. This value indicates what impact the user actually experienced, so it is the first thing to check when interpreting an error.

| User impact | Meaning                                               |
| ----------- | ----------------------------------------------------- |
| `NONE`      | No impact (normal progress or a record-keeping event) |
| `BLOCKED`   | Blocked — the normal flow was interrupted             |
| `RETAKE`    | Prompts a retake or retry                             |
| `PENDING`   | Pending — awaiting manual review                      |
| `REJECTED`  | Rejected — finalized as a final rejection             |
| `APPROVED`  | Approved                                              |
| `COMPLETED` | The relevant step is completed                        |

<Tip>
  The order for interpreting errors: **① First check the final decision events (`APPROVED`, `REJECTED`, `PENDING`) and their `reason` → ② Find the BE verification events that caused a `BLOCKED` or `RETAKE` impact at the same step → ③ Use FE observation events to additionally confirm the screen the user saw.** Do not read top to bottom in the displayed order.
</Tip>

For the full list of events and their meanings, see the [Session Journey event reference](/dashboard/en/session-journey/event-reference).