User Journey

A user journey controls which questions a respondent sees during an assessment. Without one, every control in a policy is shown. With one, a control can be made to appear only when an earlier answer calls for it — so a team is not asked about model training when they said they bought the system off the shelf.

User journeys belong to the Assessment stage, and they are configured separately from the policy itself. A policy defines what is asked; a user journey defines when it is asked. See the Overview for how Assessment fits with Authoring, Testing and Runtime Governance.

For the concept and how it appears to a respondent, see Conditional Form Logic. This page covers the configuration.

Table of Contents

The one structural rule

Conditional flow works within a single control bundle, not across bundles.

A dependency lives inside a bundle’s configuration, and both controls it refers to — the one being shown or hidden, and the one whose answer controls that — must be in that same bundle.

A cross-bundle dependency does not raise an error. It is silently ignored. When the platform works out visibility for a bundle and a dependency names a control it cannot see, that condition is skipped and the dependent control stays visible. Nothing appears in the interface to say the rule did not take effect.

This is the single most common reason a journey “does not work”. If a control is not hiding when you expect it to, check first that its parent is in the same control bundle.

If you need a question to depend on an answer in a different bundle, restructure the policy so the two controls sit together, or use a screening rule to decide which policies are attached in the first place — see Rules Configuration.

How a journey is put together 

User Journey            for one policy, its versions, roles, and organisation
└── Bundle config       one per control bundle
    └── Dependency      "this control is conditional"
        └── Input       "…on this parent control answering this way"
        └── Input       "…and on this other parent too"

A dependency can have several inputs. Every input must pass for the dependent control to show.

Fields

User journey

Field Type Required Description
policyIdentifier string Yes The policy this journey applies to
policyVersions string[] Yes Policy versions it covers. Use * to match any version
roles string[] Yes Roles it applies to. Use * to match any role
orgId string No The owning organisation. SYSTEM makes it available to every organisation
bundles BundleConfig[] Yes One entry per control bundle you want to add conditions to

Bundle config

Field Type Required Description
controlBundleIdentifier string Yes The bundle these dependencies apply to
controlBundleVersions string[] No Restrict to particular bundle versions
dependencies Dependency[] Yes The conditional controls in this bundle

Dependency

Field Type Required Description
dependentControlIdentifier string Yes The control that is shown or hidden
inputs Input[] Yes The conditions that decide it. All must pass

Input

Field Type Required Description
controlIdentifier string Yes The parent control whose answer is checked. Must be in the same bundle
answerOptionIdentifiers string[] Yes Which answer options satisfy the condition. Empty means any answer will do
isInverse boolean Yes false shows the control when the condition is met; true shows it when the condition is not met

How visibility is decided

A single condition

Situation Result with isInverse: false Result with isInverse: true
Parent has no answer yet Hidden Visible
answerOptionIdentifiers is empty, parent has any answer Visible Hidden
All listed options are selected Visible Hidden
Some but not all listed options are selected Hidden Visible

Listing several answer options means all of them, not any of them. With ["opt.a", "opt.b"] the condition passes only when both are selected — which is only reachable on a multi-select control. To show a control when either answer is chosen, list the options on separate dependencies or use a single option per input.

Several conditions on one control

All inputs must pass. Any failing input hides the control.

Chained conditions

If a parent control is itself hidden, everything depending on it is hidden too, however that parent was answered earlier. Chains resolve in order, so a control can depend on a control that depends on another.

When nothing is configured

The platform fails open at every level: no journey for a policy, no configuration for a bundle, a dependency with no inputs, or a parent the bundle does not contain — in each case the control is shown. A misconfigured journey therefore shows too much rather than hiding something a team needed to answer.

Which journey applies

Several journeys can exist for the same policy. When a respondent opens an assessment, the platform picks one by scoring the candidates and taking the best. It compares, in this order:

  1. Organisation — a journey owned by the respondent’s organisation beats a SYSTEM one.
  2. Policy version — an exact version match beats *.
  3. Role — an exact role match beats *.

A journey whose policyVersions does not contain the assessment’s version, or whose roles does not contain the respondent’s role, is disqualified — a wildcard is needed for it to apply broadly. If two journeys score the same, the most recently created wins. If none qualifies, no conditions are applied and every control is shown.

Prefer wildcards unless you mean to narrow. A journey listing policyVersions: ["1.0"] stops applying the moment the policy moves to 1.1, and the assessment quietly reverts to showing every control.

Configuring a journey

Journeys are managed in the User Journey tab of the System Admin dashboard.

Scope Who can save it
One organisation An administrator or owner of that organisation
SYSTEM — all organisations The Asenion team

Identifiers must match the policy exactly. controlIdentifier, dependentControlIdentifier and controlBundleIdentifier are the identifiers from the policy configuration, and answerOptionIdentifiers are the identifiers on the parent control’s answer options — see Policy Configuration. An identifier that does not match anything is not reported as an error; the condition simply never takes effect.

Common patterns

Show a follow-up only when a specific answer is chosen

One input, isInverse: false, one option listed. The classic “if yes, tell us more”.

Hide a question when something does not apply

One input, isInverse: true. The control is visible by default and disappears when the triggering answer is selected. Useful with a not-applicable option.

Require two things to be true

Two inputs on the same dependency, each naming a different parent control. Both must pass.

Show a control when either of two answers is chosen

Not expressible in one input, because listed options are combined with AND. Restructure the parent so the two cases share a single answer option, or split the follow-up into two controls.

Quick reference

Aspect Detail
Scope Within one control bundle. Cross-bundle dependencies are ignored
Where System Admin dashboard → User Journey
Applies to One policy, narrowed by version, role and organisation
Several options in one input Combined with AND — all must be selected
Several inputs on one dependency Combined with AND — all must pass
Hidden parent Everything depending on it is hidden too
Anything missing or unmatched Fails open — the control is shown