Onboarding

The onboarding journey (journey ID register) creates a user account. Self registration, registration by invitation and the first sign-in after an administrator created the account are all onboarding — with different settings, not different products.

Onboarding is where most customers need their own steps: checking a customer number, collecting company data, provisioning the account in their own systems. This page shows where you can add them and gives examples.

How onboarding works

The orange boxes are the injection points where you can add custom tasks. Which steps run depends on your user setup, the verification options of the application and the user (see What else determines the flow).

What is proven at which point

During onboarding, cidaas learns step by step how much it can trust the entered data. What your tasks may do depends on that:

Stage	What is proven	Your tasks can …
User (after identify, after the form)	Nothing; all data is self-asserted	Check entered data against your systems; collect non-sensitive data
Medium proven (after verification)	The user controls the email address or mobile number	Look up the customer by the proven email or mobile number; collect opt-ins
Authenticated (after the sign-in method is set up)	The user has a sign-in method for this account	Collect sensitive data (address, date of birth, company data); start identity verification; request approval

Injection points

Injection point	Stage	Allowed tasks	Typical use
after_identify	User	automated	Pre-check of the entered identifier, e.g. domain allowlist or CRM lookup
after_profile_collected	User	automated, interactive	Check a customer number; ask for additional non-sensitive data
after_medium_verified	Medium proven	automated, interactive	Find the customer or company by the proven email; marketing preferences
after_verification_method_setup	Authenticated	automated, interactive	Company data, identity verification, approval request
before_activation	Authenticated	automated	Last decision: continue, deny, or set the account to pending approval
after_activation	Authenticated	automated, interactive	Create the customer in CRM / ERP, add the user to a group, welcome page

If a check of yours fails, end the journey with a condition. You decide which message the user sees. Before the email or mobile number is proven, do not tell the user whether an account or a customer record exists.

Context variables

Variable	Type	Meaning	Write
client_id	string	Application that started the onboarding	no
inviteId	string	Invitation the onboarding was started from	no
identifier	string	Email address or mobile number the user entered. Personal data. Not proven before verification.	no
provider	string	Own credentials or the social / enterprise provider used	no
registration	object	Registration data from the form (fields of your user setup). Personal data.	partial — fields that are not locked
userExists	boolean	An account with this identifier already exists	no
verificationMedium	string	Medium used for verification	no
verificationCompleted	boolean	The email address or mobile number is verified	no
sub	string	User ID, available once the account exists	no
amr_values	array of string	Authentication methods completed	no
effectiveAutoLogin	boolean	The user is signed in automatically at the end	restrict only — true → false
effectiveAutoActivate	boolean	The account is activated without approval	restrict only — true → false
c_*	any	Your own variables	yes

Examples

Example 1: Consumer shop — link an existing customer number

The registration form contains the custom field customer number. Before the account is created, cidaas checks the number against your CRM.

Injection point	Task	Configuration
after_profile_collected	automated, Web API crm-check-customer	Input: customer number, name, postcode. Output: c_crmMatch (match, no_match, new_customer)
after_profile_collected	end on no match	Condition ctx.c_crmMatch == "no_match" ends the journey with your message
after_activation	automated, Web API crm-link-account	Input: sub, c_crmCustomerId. Writes the cidaas user ID to the CRM record

Example 2: B2B onboarding — user, organisation and user group

A business user registers with a work email. The organisation is identified, captured if unknown, checked and created as a user group in cidaas. The user is then created and added to the group.

The numbers in the diagram refer to the steps in the table.

Step	Injection point	Task	Notes
1. Pre-check the user	after_identify	automated, Web API b2b-precheck	Checks the email domain against an allowlist or your CRM. Output c_precheck. The email is not proven yet.
2. Reserve the identifier	—	cidaas	Happens after the email is verified, so nobody can block an address that is not theirs.
3a. Identify the organisation	after_verification_method_setup	automated, Web API erp-find-company	Input: domain of the verified email. Output c_organisationId, c_groupId if known.
3b. Capture the organisation	after_verification_method_setup	interactive, page c_organisation	Pre condition !has(ctx.c_organisationId). The page can validate the VAT ID through cidaas.
3c. Check the organisation	after_verification_method_setup	automated, Web API erp-check-company	Output c_companyCheck. On failure the journey ends.
3d. Create the user group	after_verification_method_setup	automated, Web API idm-create-group	Your API creates the group through the cidaas group API. Output c_groupId.
4. Create the user	—	cidaas	The account is created and activated.
5. Add the user to the group	after_activation	automated, Web API idm-assign-group	Input: sub, c_groupId. The group ID comes from your API, never from a value entered in the browser.
6. Auto login	—	cidaas	The application receives an authorization code and redeems it with its PKCE verifier. Requires that the onboarding was started by the application with an authorization request and that the sign-in method meets the application's login requirements.
7. Alternative: login page	—	cidaas	Without auto login, the user sees a page with a login entry and signs in normally.

If a new organisation needs manual approval, set the account to pending approval at before_activation. The user can complete the onboarding later through a new authorization request.

Example 3: Regulated onboarding — identity verification

A bank, an insurer or an energy supplier needs to know who is opening an account. As part of the onboarding process, there are various ways to verify this. Usually, a person is identified using their identity card or passport. You may also need to find out whether there is an existing business relationship with the user at all, and you can check this in an ‘after_identify’ step. The examples illustrate which functions cidaas supports out of the box.

Variant A: ID document and match with your customer data

The user identifies with their passport or ID card through the cidaas ID Validator. Your system then checks whether this person is already your customer, before the account is activated.

Injection point	Task	Configuration
after_verification_method_setup	identity verification with the cidaas ID Validator	The user scans the passport or ID card and passes the liveness check. cidaas takes the confirmed attributes, for example name and date of birth, into the registration data.
before_activation	automated, Web API core-match-person	Input: registration (with the confirmed attributes), identifier. Your system compares the person with your master data. Output: c_personMatch (match, no_match) and c_customerId
before_activation	end on no match	Condition ctx.c_personMatch == "no_match" ends the journey with your message. No account is activated.
after_activation	automated, Web API core-link-account	Input: sub, c_customerId. Your system stores the cidaas user ID with the customer record.

Why these positions:

• Identity verification after the sign-in method is set up. At this point the user has proven the email address or mobile number and owns a sign-in method for the new account. The verification result is bound to that account, not to an anonymous form.
• The match before activation. Only here can your task still stop the onboarding. After activation the account exists.
• Your system decides. cidaas does not search your customer data. Your API gets the confirmed attributes and answers with match or no match.

Variant B: Account from the EUDI Wallet (in progress)

In progress

EUDI wallet support is currently in active development and is expected to be available in one of the next updates of cidaas.

The user presents the person identification data (PID) from their EUDI Wallet, by QR code or on the same device. cidaas checks the credential and creates the account from the confirmed attributes; the user does not type in name, date of birth or address. The wallet shares only the attributes you ask for.

Injection point	Task	Configuration
after_verification_method_setup	identity verification with the EUDI Wallet	The user consents in the wallet. cidaas checks the issuer and status of the PID and takes the confirmed attributes into the registration data.
before_activation	automated, Web API core-check-user	Input: registration. Your system checks, for example, the age or whether the person may open a product. Condition on the output ends the journey if not.
after_activation	automated, Web API core-create-customer	Input: sub, registration. Your system creates the customer record.

The same tasks work with both variants: your API receives confirmed attributes in both cases. You can offer both ways and let the user choose.

Example 4: Invitation — partner portal

A manufacturer runs a portal for its dealers. Dealers do not register themselves: the manufacturer's partner system invites each new dealer employee. Invited users go through the same onboarding journey as everybody else; the invitation only changes what the journey knows at the start.

How the invitation starts the journey. Your partner system creates the invitation with the invitation API (email address, user group of the dealer, custom fields, initiate_login_uri of the portal). The user clicks the link in the email, the portal starts an authorization request, and the onboarding journey begins with the invitation ID in inviteId. The registration form is prefilled with the invitation data.

Injection point	Task	Configuration
after_verification_method_setup	interactive task dealer_terms, page c_dealer_terms	Pre condition has(ctx.inviteId): only invited dealers see the dealer terms. The page loads the current terms from your API through cidaas. Output: c_dealerTermsVersion
after_verification_method_setup	post condition	abort if the user declines the terms. The journey ends, no account is activated.
after_activation	automated, Web API partner-portal-activate	Pre condition has(ctx.inviteId). Input: inviteId, sub, c_dealerTermsVersion. Your partner system marks the invitation as accepted, stores the cidaas user ID and the accepted terms version, and unlocks the dealer's data in the portal.

- name: dealer_terms
  type: manual
  operationId: c_dealer_terms
  condition: 'has(ctx.inviteId)'
  outputMapping:
    termsVersion: c_dealerTermsVersion
  postConditions:
    - directive: abort

- name: partner_portal_activate
  type: automated
  executor: webapi
  operationId: partner-portal-activate
  timeout: 5s
  condition: 'has(ctx.inviteId)'
  inputMapping:
    inviteId: inviteId
    sub: userId
    c_dealerTermsVersion: termsVersion

Things to keep in mind:

• Groups come from the invitation, not from your tasks. cidaas assigns the dealer group stored with the invitation when the account is created. Do not let the page or the user choose the group.
• Self-registered users skip both tasks. Without inviteId the pre conditions are false, so the same journey also serves users who register on their own.
• The partner system learns the user ID only after activation. Before after_activation the account does not exist yet; an earlier call can only refer to the invitation.

Example 5: Marketing preferences

An online shop asks new customers whether they want the newsletter and on which channels — but only after the email address has been verified. The choice is then bound to an address the user has proven to control, and the shop's marketing system receives it once the account exists.

Injection point	Task	Configuration
after_medium_verified	interactive task marketing_preferences, page c_marketing_preferences	The page shows your opt-in texts, loaded from your API through cidaas so that the shown text version is known. Output: c_newsletter (boolean), c_channels (for example ["email"]), c_optInTextVersion
after_activation	automated, Web API marketing-save-opt-in	Pre condition ctx.c_newsletter == true. Input: sub, identifier, c_channels, c_optInTextVersion. Your marketing system stores the opt-in with the user ID, the verified address, the text version and the time.

- name: marketing_preferences
  type: manual
  operationId: c_marketing_preferences
  outputMapping:
    newsletter: c_newsletter
    channels: c_channels
    textVersion: c_optInTextVersion

- name: marketing_save_opt_in
  type: automated
  executor: webapi
  operationId: marketing-save-opt-in
  timeout: 5s
  condition: 'ctx.c_newsletter == true'
  inputMapping:
    sub: userId
    identifier: email
    c_channels: channels
    c_optInTextVersion: textVersion

Why the two positions:

• after_medium_verified, not earlier. Before verification the email address is only self-asserted. An opt-in collected at that point could be given for somebody else's address.
• after_activation for saving. If the user abandons the onboarding before the account is created, nothing is sent to your marketing system.
• The page decides nothing security-relevant. c_newsletter and c_channels are the user's own choice, so it is fine that they come from the page. Do not use values from the page for decisions such as groups or approval.

Whether the verified email address within the onboarding is sufficient as confirmation of the opt-in, or whether you need a separate double opt-in, depends on the law that applies to you. Check this with your data protection officer.

Next steps

• Custom tasks: register your Web APIs and custom pages
• Journey model: conditions and input and output mapping

Need Support?

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