8 posts tagged with "Product Enablement"

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.

If the task that follows a Manage Products task is configured with conditions that use the 'Related Products' data source, it's possible that the evaluation of that task could happen in parallel to the propagation of product data due to parallel processing. To support this configuration scenario, we have introduced a new configuration toggle to the Manage Products task. When enabled (optional) the 'Ready For Sequential Task Evaluation' toggle will hold the Manage Products task from closing until propagation of product data to other sources has completed. When the next task triggers, product data changes will be fully available for evaluation.

We released Product Risk Assessment in May of this year. The feature will assess the risk of products that were added/updated in the current journey. Some clients also want to included 'Onboarded' products in Product Risk Assessment so that migrated products can be assessed for the first time or previously assessed products to be reassessed against the latest configuration. Verified data is never directly changed, so we need to bring onboarded products into review in order for them to be assessed. We're introducing the 'Create Onboarded Product Drafts' Service task to automate the effort to include these products in the scope of a Product Risk Assessment. The task will only open drafts for Onboarded products that are Owned by the root entity and can be further configured with a Product Scoping Rule for scenarios where only a subset of onboarded products need to be re-assessed.

'Number' type Product Requirements can now be configured with 'Conditional Limit' validations which are configured relative to other number requirements in Product data ('Current Product' source) or Entity Data ('Related Entity' source) using operants. In addition, Product Requirements can also be used as a trigger for columns and conditional values in data groups linked to the same product. Further we've introduced the 'Current Product' source for Logic Engine conditions configured Trigger Conditions or Conditional Values. This source allows conditional behaviours to be driven based on product requirements in the product the datagroup is linked to.

Aligning with recent enhancements to Policy, Product 'Date' requirements can now be configured with a validation time zone. This can be used with three validations: No Past Dates, No Future Dates and Disallow Todays Date. When setting a 'Default Value' for a date requirements as 'Default to todays date', the default value will be set according to the date in that time zone (when triggered). If there is no value selected in 'Validation Time Zone', UTC will be used to determine the date in these circumstances. Note: The 'Date Range' validation in product requirements can reference relative values like 'Today', however this will continue to follow UTC for the time being.

Previously, cloning a product required manaully adding Related Parties to the cloned product. It's now possiblet to include up to 50 Product-Related Party Connections with the cloned product. If there are greater than 50, the user will be alerted that the Products Related Parties will not be included if they proceed.

Aligning with Policy, it's now possible to configure data groups as read-only within Product Requirement Sets. This allows data groups to be configured as read-only, which can benefit review contexts or where the integrity of data populated by external systems needs to be preserved. To configure a read-only data group, simply select the 'Validations' tab when configuring a Product Requirement Set with a Data Group type requirement and toggle on 'Read Only'.