22 posts tagged with "Product Enablement"

This release introduces a new "Clear Value if Trigger Condition Not Met" toggle in the policy editor for entity and product level. When enabled on a data requirement, if all associated trigger conditions for a field are no longer satisfied, any previously saved value is automatically cleared at both the product or entity levels. This ensures that hidden fields no longer store an invalid value. The toggle is opt-in and defaults to off.

See user guide for the full configuration guide and behaviours to note with this new functionality:

Configurators can now include product types in a Shared Data Template. When a Group Onboarding journey runs, verified products of those types on the Group entity are automatically shared to each in-scope child entity — removing the need to create products separately for every member of a joint account or entity group.

Fenergo now allows for the capture of three system-calculated, read-only date fields in the Product domain — recording when each product was onboarded, last updated, and offboarded. These dates are tracked individually per product, ensuring accuracy across all lifecycle events. Each field would need to be added to a product policy to be visible and will need a specific datakey. See user guide for more information on configuration steps.

Tags and References can now be added to Product Requirement Set requirements, bringing the Product domain in line with the capability already available in Policy. Tags are a flexible way to group requirements — labels you define to suit however you want to group them, applied across requirement types and jurisdictions so that every requirement matching one or more tags can be retrieved and reviewed together. References let you record the external legislation or internal documentation behind a requirement.

Screening V2 introduces two redesigned screening tasks across On Demand Screening (ODS) and Ongoing Screening (OGS). A new ODS: Screening Resolution & Materiality task combines hit resolution, hit classification, and materiality assessment — including, for the first time, materiality at Related Party (RP) level with one consistent outcome stored per RP. A new two-stage OGS: Screening Resolution & Client Selection task formalises the review of hits from periodic screening and drives the right downstream work per affected client.

Search Text Fields are now supported within Product Requirement Sets and linked Data Groups. Now, when configured within products, users can retrieve values from an external or (Flows simulated) data source via a Policy Custom Search Provider. This facilitates ensuring that a correct value is selected from a trusted source (for example email address or external identifiers).

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".