Product Scoping Rules can now be imported via Configuration Exchange, both as direct selections and as automatic dependencies of journey schemas that reference them in a Manage Products task. Once imported, the Manage Products task in the target tenant uses the version of the Product Scoping Rule that was selected during the import.
The Conflict Resolution task has been updated so that users only see the products and product fields they are entitled to see. Configurators also have the option to nominate Product Categories whose conflicted fields should default to "Current Verified Data" instead of "This Journey".
This feature introduces the ability to have the Manage Products Task be completed by the Autocompletion agent. This can be configured within the journey builder.
Product Access Layers are calculated on 'Save' in the Manage Products task. If users lack the resulting access layers, they will lose access to that product and be unable to edit it further.
We're introducing a warning toast that monitors product field changes and alerts the user when current inputs will result in an access layer they lack, recommending to finalise all required inputs for the product before saving. This mitigates the risk of an inaccessible and incomplete product that may otherwise block task completion.
When adding related parties to a product the user will now have the ability to select existing related parties that are sourced from the main client's related party list. This removes the need for users to re-search and re-add Related Parties at the Product level even when those Related parties already exist on the client.
We've made some minor adjustments to the way that data is saved and validated within the Manage Products task. These changes are expected to improve performance by reducing the volume of changes that are saved at one time.
This release introduces a new configuration option for Product Scoping Rules of type Connected Journey, allowing you to control whether matching products are grouped into a single connected journey or launched into separate connected journeys.
This release introduces a new Product Journey Checkpoint task type for onboarding journeys that launch multiple product-specific connected journeys in parallel. The checkpoint acts as a synchronisation point in the parent journey, ensuring product-level work is finalised before the parent journey proceeds to subsequent steps (for example, client-level verification and activation).
This release enables you to:
Product Journey Checkpoint must be placed in a sequential stage and process that comes after the Product Journey Launchpad taskWhen the Product Journey Checkpoint task becomes active, it identifies all connected journeys launched by the Product Journey Launchpad task from the same parent journey and displays them in a table with the following columns:
Product Access Layers (PALs) and Product Field Access Layers (PFALs) introduce a dedicated security model for product data. These controls allow clients to restrict which products a user can see, and which product fields they can view, based on Business Related and Geographic access layer entitlements.
This ensures product visibility is governed independently of the owning Entity, providing stronger information barriers and more precise access control across all product-related features.
Onboarding diverse products in a single Journey can delay activation for simpler items. With Product Connected Journeys you can launch dedicated, parallel journeys for specific products or groups of products, using configurable Product Scoping Rules to define which products qualify based on your criteria. The progress of these parallel journeys can be held against gates configured in the parent journey to ensure due-diligence requirements have been satisfied before they are activated. This creates a path for simpler products or those with already-satisfied due-diligence requirements to be actiaved much faster, without being blocked by unrelated parent journey activities.