Dynamic Access Layer rules for Products can now use Lifecycle Status as a condition, and Product Access Layers are re-evaluated when the Verify Products V2 task is completed using the expected post-verification status. Together this allows access to a product to vary across its lifecycle — for example a pending merger or private deal can be restricted while in draft and opened up once it becomes Onboarded.
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.