Separate sets of Proposition Filters (and hence sub-strategies) are required for each issue and group combination in the taxonomy, and for each context level within that combination. In addition, a further set of All Actions Proposition Filters may be optionally defined that apply to actions from all contexts.

An additional set of Engagement Policies may be defined at the top of the taxonomy hierarchy for all issues and all groups, and these are applied to all actions in any issue and group. Just like the individual issue and group-level policies, a separate policy may be defined for each context, and each of these has a separate proposition filter for each of the Eligibility, Applicability and Suitability conditions.

All Actions Engagement Policies

The All Actions strategy is executed first, and the strategy used depends on the trigger strategy as described in the table below.

These strategies are generated by Next-Best-Action Designer and are not modifiable.

The following figure shows an example of the top-level All Actions strategy for issues Selling, Retention and Acquisition:

Next is an example of an issue-level All Actions strategy for the Selling issue with groups Mobiles and Plans:

Finally, the following example shows the group-level strategy containing the Eligibility, Applicability and Suitability proposition filters for the Selling issue, and Mobile group:

The Offer Collector shape sets the UniqueID property for internal use, and there are four exit points:

• Best Result is used by the Next-Best-Action Strategy Framework for actions that pass all conditions.
• Eligibility, Applicability and Suitability are used by the Simulation feature to show how actions successively drop out as they progress through the filter stages.

Since these All Actions proposition filters are all executed at the top context level, they need access to the data page from that context which is defined in the Pages & Classes tab of the proposition filter definition. The page name is the same as the context name and is passed to the proposition filter via the Available pages & classes section of the Filter properties shape, as shown in the example below for the Account context:

Context-level Engagement Policies

The individual context level strategies are executed next and again will depend on the trigger strategy as described in the table below. Note that a separate strategy is executed for each context in the context dictionary.

These strategies are generated by Next-Best-Action Designer and are not modifiable.

The following figure shows an example of the top-level Account context strategy for issues Selling, Retention and Acquisition:

Next is an example of an issue-level Account context strategy for the Selling issue with groups Mobiles and Plans:

Finally, the following example shows the group-level Account context strategy containing the All Issues / All Groups strategy and the Eligibility, Applicability and Suitability proposition filters for the Selling issue, and Mobile group:

The Offer Collector shape sets the UniqueID property for internal use, and these strategies also contains a NBA Property Expressions sub-strategy for evaluating custom property expressions – a new feature introduced in Pega Customer Decision Hub 8.6.

There are four exit points:

• Best Result is used by the Next-Best-Action Strategy Framework for actions that pass all conditions.
• Eligibility, Applicability and Suitability are used by the Simulation feature to show how actions successively drop out as they progress through the filter stages.

Since these context-level proposition filters need access to the data page from the context they are evaluating, and also for any of the pages for the higher-level contexts, all such pages are defined in the Pages & Classes tab of the proposition filter definition. The page names are the same as the context names and are passed to the proposition filter via the Available pages & classes section of the Filter properties shape, as shown in the example in the example for the All Actions Engagement Policies.

Furthermore, all of the sub-strategies that are called on the way to access these proposition filters also need these page definitions in their Pages & Classes tab, and need to pass the page data using the Available pages & classes section of the sub-strategy shape as shown in the example for the top-level Device context below: