SumsubUser action with decisionBeta

Step-up liveness (Sumsub)

Requests targeted proof of presence from Sumsub for an existing applicant, then routes the process on the action decision.

Business object

Step-up présence (Sumsub)

Approuvé

Rejeté

Relance

Revue requise

Applicant Sumsub

Action applicant Sumsub

Vue d’ensemble

Objectif

This node is for one-off enhanced checks: reconfirm that the person is present before a sensitive operation without replaying the full identity journey.

It creates a Sumsub applicant action on the applicant already linked to the contact, opens WebSDK on that action, then waits for extension.sumsub.applicant_action_reviewed.

liveness_check is the main business output: it carries result, decision, review_answer, review_reject_type, and Sumsub rejection labels.

The node routes directly on liveness_check.decision with approved, rejected, retry, and review_required branches.

When the liveness decision is terminal, the node directly materializes the corresponding platform.compliance_check with check_type: liveness under its write permission.

Quand l’utiliser

You already verified contact identity with Sumsub and want lightweight reverification at a risk-sensitive moment.
You need to protect a sensitive operation, for example a high payout, payment-method change, or critical administrator action.
You want to correlate the decision to the precise action, not only the global applicant.

Parameters 7

extension_config_idRequisref(extension_config:sumsub)

Active Sumsub provider configuration.

subjectRequisContact

Natural-person contact concerned. The node requires a persisted contact because step-up reuses an existing Sumsub applicant.

sumsub_applicantOptionnelSumsub applicant

Sumsub applicant to use directly. When absent, the node resolves it through the contact's provider mapping.

level_nameRequisstring

Name of the Sumsub applicant-action level configured for liveness step-up.

onboarding_caseOptionnelOnboarding case

Business case to attach to the materialized compliance_check.

scopeOptionnelstring

Business scope of the check. Default: step_up.

external_action_idOptional · advancedstring

External identifier sent to Sumsub for the action. By default, Ormuz generates a stable identifier from the process instance and node.

Outputs 5

sumsub_applicantSumsub applicant

Sumsub applicant reused to create the action.

sumsub_applicant_actionSumsub applicant action

Sumsub action created for this one-off check. Its object/id pair is used to correlate asynchronous resume.

liveness_checkSumsub liveness check

Provider-native business result of the presence check. liveness_check.decision is the source of node routes.

selected_routeenum

Route selected by the node, derived from liveness_check.decision.

action_compliance_checkOptionnelCompliance check

Persisted liveness Compliance Check created or reused after a terminal Sumsub action decision.

Behavior

Reuse the applicant

The node uses the supplied applicant or finds the contact's through extension_object_mappings. If none exists, the process must first go through an identity journey.

Create the targeted action

Ormuz creates a Sumsub applicant action with a stable externalActionId and generates a WebSDK token scoped to that action.

Wait for the decision

After user submission, the process waits for extension.sumsub.applicant_action_reviewed correlated to sumsub_applicant_action.id.

Route the journey

liveness_check.decision becomes selected_route. approved continues the sensitive operation, rejected blocks it, retry restarts the step-up, and review_required branches to manual review.

Materialize the check

A terminal decision is materialized as a canonical compliance_check with provider provenance. GREEN becomes passed and RED FINAL becomes failed; RED RETRY remains a retry route and does not materialize a terminal fact.

Process example