ConditionalResumeFrom - User Guide

Overview

What problem this solves

• Workflows can involve multiple user personas (e.g., customer vs agent).
• Without additional controls, a resumed session may land on (or allow access to) modules that should only be completed by a specific persona.

How it works (high level)

• A module or super-module can declare conditionalResumeFrom in its properties, pointing to a conditional variable.
• When CPR prepares the resume execution order (MEO), it evaluates that conditional variable and decides whether the user should resume from:
  • a specific module/super-module id, or
  • the special constant self_module (meaning "resume from the same module where this property is defined").

Example (agent-assisted onboarding)

• Customer starts onboarding and drops at Selfie Verification.
• Agent resumes the journey — without conditionalResumeFrom, they can attempt the selfie verification step.
• With conditionalResumeFrom, the agent is redirected to a safe module (e.g., Main Form Screen) instead of Selfie Verification.

Prerequisites

• Workflow should be non-linear.
• Workflow is performed by multiple users (personas).

Step-by-step guide

Builder configuration

JSON example:

// module config
{
  "moduleId": "module_selfie",
  "properties": {
    "url": "https://ind-thomas.hyperverge.co/v1/checkLiveness",
    "apiType": "multipart_post",
    "validateSignature": false,
    "showEndState": "yes",
    "conditionalResumeFrom": "conditionalVariables.condVar_Tj7TDc"
  }
}

// conditional variable defined by the user
"condVar_Tj7TDc": {
  "if_false": "self_module",
  "if_true": "module_main_form",
  "rule": "inputs.userType == 'agent'",
  "name": "Restrict basis user's role"
}

Validations

• This feature only works with non-linear journeys where indexPage property is added in the workflow.
• conditionalResumeFrom must reference a workflow-defined conditional variable.
• The conditional variable rule can only use:
  • inputs, module outputs. Example: "rule": "inputs.userType == 'agent'"
  • The rule cannot reference other conditional variables (nested conditional variables are not allowed).
• if_true / if_false of the conditional variable must be:
  • a valid moduleId, or
  • "self_module" (string constant).

Common incorrect configs

Referencing other conditional variables in the rules:

"condVar_Tj7TDc": {
  "if_false": "module_demat_account_statement",
  "if_true": "self_module",
  "rule": "conditionalVariables.condVar_A6Kh4i == true", // Incorrect
  "name": "Restrict basis user's role"
}

Nested conditional variables:

"condVar_Tj7TDc": {
  "if_false": "module_demat_account_statement",
  "if_true": "conditionalVariables.condVar_A6Kh4i", // Incorrect: nested conditional variable
  "rule": "conditionalVariables.condVar_A6Kh4i == true",
  "name": "Restrict basis user's role"
}

If the above validations are not followed, the feature will not work as expected.

Important points

• All resumeFrom values should be one of the modules of the same branch or the index page.
  • Example: main_form → m1 → m2 → m3 → main → m4 → m5 → m6 → auto_declined — possible resumeFrom values: [main_form, m4, m5, m6].
  • Setting resumeFrom to a module in another branch (e.g., [m1, m2, m3]) is not allowed.
• If a module defined in a conditional variable is not part of the Module Execution Order, the feature processing is skipped and the original MEO is returned.
• If a loop is formed with conditionalResumeFrom, the original MEO is returned:

graph TD
    A[Module A] -->|"roleBasedAccess.condition = true<br/>resumeFrom = B"| B[Module B]
    B -->|"roleBasedAccess.condition = true<br/>resumeFrom = C"| C[Module C]
    C -->|"roleBasedAccess.condition = true<br/>resumeFrom = A"| A

    style A fill:#f9d5e5,stroke:#333,stroke-width:2px
    style B fill:#eeeeee,stroke:#333,stroke-width:2px
    style C fill:#d5e8f9,stroke:#333,stroke-width:2px