All sub-organisations are created by GBG.
What you can do
You use the same journey-building tools as a customer, then share the resulting journeys with your sub-organisations. As a partner, you can:- Create a journey for your sub-organisations to use.
- Configure modules to add verification checks to a journey.
- Set up routing to control how a journey branches.
- Set up evaluation to define outcome and decision logic.
- Publish a journey to make it available to your sub-organisations.
How sharing works
When you share a journey, your sub-organisations receive a reference to it rather than a copy. Sub-organisations donβt own a duplicate of the underlying resource. Sharing has the following characteristics:- Updates apply automatically. When you update a journey, all sub-organisations use the updated version. There is no manual propagation step.
- Journey IDs stay the same. You use the same journey resource ID in the partner organisation and in each sub-organisation.
- Sharing is one-directional. Resources always flow from the partner down to sub-organisations. Sub-organisations canβt push resources up.
When you update a journey
When you modify and republish a journey, the update applies as follows:- The updated version applies to all sub-organisations. The sub-organisation does not need to take any action.
- New sessions that reference a specific version use that version, not the update. To run the updated journey, start the session against the new version.
- New sessions that reference the journey as
@latestuse the updated version. Use@latestwhen you want updates to reach sub-organisations without changing your integration. Name a specific version when you need to control exactly which version each session runs. - In-flight sessions continue with the version they started on.
What gets shared
The partner organisation manages shared resources centrally. Each sub-organisation manages its own account-level resources.
Users and roles apply to people who sign in to the GBG GO platform directly. Each organisation creates its own users and assigns their roles. Single URL Login works differently: you request the role or permissions for each session, and the session never holds more than your own credentials hold.