Override journey settings for sub-organisation

A sub-organisation can customise specific journey settings it inherits from a parent organisation, without cloning the journey. This is for cases where each sub-organisation needs different operational values, while the parent keeps control of the journey structure and decisioning. For example, each sub-organisation might need its own PEPs and Sanctions worklist ID, or its own Facematch Verification match threshold.

​

What this feature does

A sub-organisation inherits a journey from its parent and overrides selected settings for that inherited journey. The journey itself stays shared, so the sub-organisation doesn’t create or maintain its own copy. This gives you a controlled way to vary local settings while preserving a single parent-managed journey definition. In short, parent organisations control what runs, and sub-organisations tailor the allowed settings.

​

What can and cannot be overridden

• Can be overridden: module and journey settings that are exposed for sub-organisation use, such as authored values on a node.
• Cannot be overridden: anything that changes journey structure or decision logic. If those need to change, then create a new journey instead.

This boundary is intentional. It keeps sub-organisation flexibility narrow and safe.

​

How a sub-organisation overrides a setting

Sub-organisation admins use the inherited journey in their own designer experience. They don’t edit the full journey. Instead, they edit only the settings that are available for override.

1. Open the shared journey in the sub-organisation designer.
2. Select the relevant node and open its Settings.
3. Review which fields are editable.
4. Enter the sub-organisation-specific value for each setting that needs to differ from the parent.
5. Save the changes.
6. Click Reset on a field if the sub-organisation should return to inheriting the parent value.

Editable fields use the parent value as the default. If a sub-organisation doesn’t supply its own value, then the parent value continues to apply. The sub-organisation experience is focused on settings only:

• The journey is still parent-managed.
• Areas that can’t be overridden remain visible but not editable.
• The sub-organisation can see what the journey uses, without being able to change structure or logic.

​

Runtime behaviour and precedence

At runtime, the platform resolves the inherited journey first, then applies the sub-organisation’s allowed overrides before dispatching the node to its module. The precedence rule is:

1. The parent journey provides the base settings.
2. The sub-organisation’s override values are applied on top of the allowed settings.
3. The resulting node configuration is what the module receives at execution time.

The sub-organisation override wins over the inherited parent value for supported settings. This is why the feature works safely for operational settings. The override is applied into the node configuration before module dispatch, rather than relying on caller-supplied input later in the journey.

​

Guidance for integrators and admins

Use the following model:

• Parent organisation: owns and publishes the journey.
• Sub-organisation: inherits that journey and customises permitted settings only.
• Integrator: continues to start the same inherited journey. The platform resolves the correct effective settings at runtime.

Use this feature when sub-organisations need different local settings but should still run the same journey logic as the parent. Use a new journey instead if the requirement is to change variant selection, evaluations, outcomes, topology, or any other structural behaviour.

​

Frequently asked questions

​

Next steps

• Share a journey with a sub-organisation: Link journeys to sub-organisations.
• See what else is shared from a partner organisation: Overview.