> ## Documentation Index > Fetch the complete documentation index at: https://docs.go.gbgplc.com/llms.txt > Use this file to discover all available pages before exploring further. # Override journey settings for sub-organisation > A sub-organisation can customise selected settings in a journey it inherits from its parent organisation, without cloning the journey. 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. | Area | Supported? | Notes | | ---------------------------------------- | ---------- | -------------------------------------------------------- | | Settings | Yes | Used for values like worklist IDs and match thresholds. | | Variants, topology, nodes, and edges | No | These are structural changes and require a new journey. | | Evaluations and outcomes | No | Sub-organisations cannot change how the journey decides. | | Credentials and arbitrary internal paths | No | Not valid targets for this feature. | 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. | Scenario | Result | Why | | ---------------------------------------------------------- | ---------------------------------- | ------------------------------------------------------------------ | | The sub-organisation has saved an override | The sub-organisation value is used | The allowed override replaces the parent setting. | | The sub-organisation has not saved an override | The parent value is used | Inheritance remains the default behaviour. | | The sub-organisation tries to change unsupported behaviour | No structural change is applied | Only allowed settings are resolved through the override mechanism. | ## 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 If the sub-organisation clears or resets an override, then the journey falls back to the parent-authored value for that setting. No. This feature is for settings only. Any change to decision logic or journey structure requires a different journey. No. The journey remains shared from the parent. Only the allowed settings differ for that sub-organisation. ## Next steps * Share a journey with a sub-organisation: [Link journeys to sub-organisations](/docs/go-v1/platform/partner-login/assign-journeys-to-sub-organisations). * See what else is shared from a partner organisation: [Overview](/docs/go-v1/platform/partner-login/overview).