For the complete documentation index, see llms.txt. This page is also available as Markdown.

Additional information requests

Request additional verification steps from applicants within an existing session, without losing audit history.

How it works

When an operator triggers an additional information request, a new verification link is generated for the applicant. The operator sends it via Manage — by SMS, email, or by copying and sharing the link manually. The session ID visible in Manage remains the same throughout all verification requests.

Upon opening the link, the applicant is presented only with the steps defined in the new verification request. Previously completed steps are not shown to the applicant and their data is not modified.

Decisions (automatic or manual) apply to the current verification request only. Once all steps in the request are completed, the standard decision flow runs as normal.


Session status

A new session status is introduced for this feature:

Status
Description

additional_information_requested

The session has been returned to the applicant for further verification. Sits between a terminal state and in_progress.

Status transitions:

approved / rejected / manual_check / expired

additional_information_requested
        ↓ (applicant opens the link)
in_progress

approved / rejected / manual_check

Verification history

A session can go through multiple verification requests over its lifetime. Each request generates its own set of steps based on the selected configuration. If a step type was completed in a previous request, it is generated again as a new attempt — full history is preserved and accessible for audit purposes. The latest attempt per step is used for review and decision-making.


Enabling the feature

  • How to enable: Toggle this setting on in the Configuration settings tab of the configurations builder.

When enabled, operators will see the Request more information button on eligible sessions in Manage.

Configurations available for selection when making a request are filtered by the operator's group membership, consistent with access control rules applied elsewhere in the platform.

Last updated

Was this helpful?