# Applicant Timeline

Timeline functionality provides a detailed, chronological record of all actions taken on an applicant’s profile. This feature is essential for maintaining transparency, tracking changes, and ensuring compliance with regulatory requirements. The logs allow compliance officers to review all updates, edits, and actions associated with an applicant's verification process.

* From the Applicant profile, click on `Timeline` to open the profile changes history:

<figure><img src="/files/GO5TlyD66wG67xdU8Uym" alt=""><figcaption></figcaption></figure>

* The timeline interface displays a series of logs, each entry detailing a specific action taken by an applicant or on the applicant's profile.\
  Each log entry includes the date and time of the action, providing a clear, chronological sequence of events:

<figure><img src="/files/g8KcVMFo6ck8R6UYPXvL" alt=""><figcaption></figcaption></figure>

### How to Read the Timeline (Chronology Explained)

The **Timeline** in Allpass.ai shows a complete, real-time record of every action taken during a user’s verification journey — from the moment the session starts until it's completed, rejected, or left incomplete.

* The **Timeline** is presented in **reverse chronological order** (most recent action at the top).
* Each entry includes:
  * **Timestamp** (date and time of the event)
  * **Event description** (e.g., “OTP code sent”, “Email verification completed”)
  * **Step status** (e.g., “Accepted”, “Incomplete”, “Rejected”)
  * **System or user actor** (e.g., “Changed by system”, “Initiated by applicant”, or staff member name)
  * **Metadata** (e.g., IP address, location, browser)

#### **How to Read It Step-by-Step**

1. **Start from the bottom** to see how the verification flow began:
   * You’ll usually see events like:
     * *“Applicant profile created”*
     * *“Verification initiated”*
     * *“Review status: init”*
2. **Move upward to follow the user journey**:
   * Each step in the workflow will generate one or more logs.
3. **Top of the timeline = most recent status**
   * The current state of the application is shown here.

{% hint style="info" %}
**Tip for Troubleshooting**

> Start from the bottom to understand the path the user followed, then look for the first step that **did not complete**, was **skipped**, or shows **a red status**. That’s often where the issue lies.
> {% endhint %}

***

### What Each Status Means

<table><thead><tr><th width="126.74609375">Status</th><th>What it means</th><th>When you'll see it</th><th>What to check </th></tr></thead><tbody><tr><td>OPEN</td><td>The step has been initiated but not yet completed by the user.</td><td>A verification step was launched (e.g., document upload or liveness check), but the user hasn’t finished it.</td><td>This may indicate an <strong>abandoned session</strong>, user confusion, or a drop-off. If no follow-up log appears, the user likely exited before finishing.</td></tr><tr><td>COMPLETED</td><td>The step was successfully finished by the user.</td><td><p></p><p>After a user completes a task such as email verification, document submission, or a questionnaire.</p></td><td>This is a good sign — move up the timeline to confirm whether the next steps were also completed.</td></tr><tr><td>FAILED</td><td>The system attempted to process the step but it did <strong>not pass</strong> due to an error or invalid input.</td><td><p></p><ul><li>A verification step was <strong>started but didn’t meet required conditions</strong>.</li><li>The system detected a mismatch, error, or incomplete data that prevented the step from being marked as successful.</li></ul></td><td>Compare timestamps for retries.</td></tr><tr><td>ACCEPTED</td><td>The system or a reviewer <strong>approved the step</strong> or the entire application.</td><td>After a step passes validation.</td><td><p></p><ul><li>If this is the final step, it usually means the user is fully verified.</li><li>If earlier in the process, verify that later steps are also accepted or completed.</li></ul></td></tr><tr><td>REJECTED</td><td>A step was <strong>reviewed by a person or a rule</strong> and explicitly rejected.</td><td><p></p><ul><li>A compliance officer manually rejects a submission.</li><li>A rule-based filter automatically flags and rejects the verification (e.g., due to sanctions match).</li></ul></td><td>Look for review logs, decision notes (if enabled), or error reasons in adjacent logs.</td></tr></tbody></table>

***

### Understanding Location, Device, and IP Metadata

Each log entry in the **Timeline** includes technical metadata that helps you understand **where**, **how**, and **on what device** the verification flow was accessed.

#### What Metadata Is Displayed?

For most events, you’ll see:

* **Device & OS**\
  Example: `Mac OS v10.15.7 / Chrome v113.0.0`\
  → Indicates the operating system and browser used by the applicant.
* **IP Address**\
  Example: `185.5.252.60`\
  → The public IP address assigned to the user during the session.
* **Location**\
  Example: `Ukraine`\
  → Based on geolocation data tied to the IP address (note: this is an estimate).
* **“View on map” link**\
  → Opens a visual map to help you validate if the user's geographic location aligns with expectations (e.g., not using VPNs or proxies).

***

### How to spot user-side vs. system-side errors&#x20;

When something goes wrong during a KYC/AML flow, it’s important to know **where the failure happened** — was it due to the user's input or device? Or did the system itself encounter an issue?

The **Timeline** provides clues to help you quickly identify whether an error is **user-side** or **system-side**, so you can take appropriate action (e.g., follow up with the user, restart a step, or escalate internally).

#### General Rule of Thumb

* **User-side errors** = The user failed to complete an action or submitted incorrect/incomplete input.
* **System-side errors** = The platform or API failed to process something correctly (rare but critical).

#### **User-Side Errors Examples: What to Look For**

| Log Clue                                    | What It Means                                          |
| ------------------------------------------- | ------------------------------------------------------ |
| `OTP step open` but no `OTP verified`       | User didn’t enter or confirm the code                  |
| `Email verification sent` but not completed | User didn’t click the email link                       |
| `Liveness step started` but no success log  | User may have denied camera access or failed the check |
| `Questionnaire step open` without follow-up | User dropped off or didn’t submit required answers     |

{% hint style="info" %}
**Pro tip:** If the last step before “Incomplete” status is one of the above, it’s likely the user abandoned or made a mistake in that step.
{% endhint %}

#### **System-Side Errors Examples: What to Look For**

| Log Clue                                                        | What It Might Indicate                             |
| --------------------------------------------------------------- | -------------------------------------------------- |
| `Step failed due to timeout or API error`                       | Internal issue or connection problem               |
| `Document check failed: server error`                           | Third-party provider temporarily down              |
| `Review status changed by system` without a user-triggered step | Automated logic or fallback triggered unexpectedly |
| Timestamps or steps skipped entirely                            | Platform bug, logic misfire, or misconfiguration   |

{% hint style="info" %}
If something looks off and there’s no corresponding user action, contact your Allpass.ai support team for escalation.
{% endhint %}

#### **Combined Case Example:**

* **Email step sent** ✅
* **No OTP entered** ❌
* **Review status: Incomplete**\
  → This is a **user-side issue** — most likely they didn’t follow through.

{% hint style="info" %}
**Tip for Teams**

> Encourage your support or compliance team to **check the last 3 logs** before a failure or incomplete status — 9 times out of 10, this window will show whether the problem was on the user’s end or the system’s.
> {% endhint %}

***


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.allpass.ai/review-data/applicant-timeline.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.