Journey model

This page explains the building blocks of a user journey: tasks, conditions and the journey context. You need them to add your own tasks (see Custom tasks).

Tasks

A user journey is an ordered list of tasks. cidaas runs them from top to bottom.

Type	What it does	Example
Interactive	Shows a hosted page and waits until the user completes it	Login form, your own consent page
Automated	Runs on the server without a page	Call to your CRM, risk check

Each task has a name, unique within the journey, and can have a timeout:

• interactive task: how long cidaas waits for the user,
• automated task calling your API: how long cidaas waits for the response.

Pre conditions

A pre condition decides whether a task runs. Without a pre condition the task always runs. If the pre condition is not met, cidaas skips the task and continues with the next one.

Pre conditions are written in the Common Expression Language (CEL). They can use:

• ctx — the journey context (see below),
• results — the results of earlier tasks: results.<task>.status and results.<task>.output.

# Show the company page only if the company is still unknown
condition: '!has(ctx.c_companyId)'

# Run only after the CRM check has completed
condition: 'results.crm_check.status == "completed" && ctx.c_crmMatch == "match"'

Post conditions

After an interactive task, the user can go forward, go back to change something, or cancel. Post conditions define what happens:

Directive	Meaning	goto
forward	The user completed the page. Without a matching post condition cidaas continues with the next task whose pre condition is met.	optional
edit	The user wants to change an earlier entry.	required
undo	Go back and discard the results from a given task onward (invalidateFrom).	required
abort	The user cancels. The journey ends.	optional

Each post condition can have its own CEL condition. goto jumps to another task of the journey; the target must be an interactive task. Automated tasks support only forward.

postConditions:
  - directive: edit
    condition: 'results.company_details.status == "completed"'
    goto: company_details
  - directive: abort

Journey context

The journey context holds the data of the running journey, for example the user ID (sub), the application (client_id) or the authentication methods used (amr_values). Each journey page lists the context variables you can use: Login, Onboarding, Account recovery.

A task does not see the whole context. An automated task receives only what you map into it. An interactive task — your custom hosted page — receives no context data at all: the page gets its data from your API through cidaas (see Custom tasks). Both change the context only through what you map out of them:

Input mapping (in-context)

Maps context variables to the input of an automated task, for example the request to your API. Key: variable in the journey context. Value: name in the task. Interactive tasks have no input mapping.

inputMapping:
  sub: userId
  c_customerNumber: customerNumber

A task without input mapping receives no data.

Output mapping (out-context)

Maps fields of the task result to context variables. Key: field in the task result. Value: variable in the journey context.

outputMapping:
  match: c_crmMatch
  customerId: c_customerId

Later tasks can then use ctx.c_crmMatch in conditions or map it into their input.

An empty value removes the variable

If a mapped field is empty ("") or null, the target variable is removed from the context. A later has(ctx.c_crmMatch) is then false.

What a task may write

Your tasks can read the context variables listed on each journey page. Writing is restricted:

Write rule	Meaning
Your own variables	Names that start with c_, for example c_customerId. You can create, change and remove them.
no	The variable belongs to cidaas and cannot be changed, for example sub, client_id, amr_values.
restrict only	The variable can only be changed to the stricter value, for example smartMfaRequired from false to true (you can require MFA, never waive it).
partial	Only certain parts can be changed, for example registration fields that are not locked.

The write rule of each variable is listed on the journey page. A value of yours reaches the token only if you map it into a claim explicitly.

Next steps

• Custom tasks: where you can add tasks and how they call your systems

Need Support?

Please contact us directly on our support page or reach out to cidaas support at [email protected].