19 posts tagged with "Product Enablement"

Clients using Automatic Offboarding with policies scoped by Related Products conditions will now see more consistent outcomes for their client entities during Ongoing Screening journeys. Policy evaluation calls made during Ongoing Screening journeys now include the Related Products data source, bringing them into line with all other journey types.

This means that policies referencing Related Products data are evaluated with the correct data available throughout the Ongoing Screening lifecycle, and automatic offboarding decisions accurately reflect whether scoping conditions are genuinely met.

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:

• Add a Product Journey Checkpoint task to a Journey Schema in Journey Builder.
• Pause a parent journey until all connected product journeys launched from the same parent are finalised.
• View the set of launched connected journeys directly within the checkpoint task and navigate to them (subject to existing access permissions).

Configuration rules and validation​

• A Journey Schema can contain only one Product Journey Launchpad task.
• A Product Journey Checkpoint task can be added only to a Journey Schema that contains a Product Journey Launchpad task.
• The checkpoint must be placed in a sequential stage and process that occurs after the stage containing the Launchpad task.
• If a user attempts to save a Journey Schema that violates these placement rules, the save fails and an error toast is displayed:
  • Product Journey Checkpoint must be placed in a sequential stage and process that comes after the Product Journey Launchpad task
  • The invalid journey elements are highlighted in red.

Runtime behaviour​

When 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:

• Journey (the Product Scoping Rule name that triggered the connected journey)
• Name (the connected journey instance name; hyperlink to open, subject to permissions)
• Journey Status
• Application Status
• Started

Completion logic​

• The Complete button is disabled by default.
• The Complete button is enabled only when all listed connected journeys have a Journey Status of Complete or Cancelled.