Skip to main content


         This documentation site is for previous versions. Visit our new documentation site for current releases.      
 

NBA Strategy framework extension points

Updated on August 4, 2022

The Next-Best-Action strategy has a number of predefined extension points that you can use to add your own business logic to the framework. For example, you can use extension points to apply additional contact policies, or adjust model propensities. For a list of available extension points, see below.

Pega Customer Decision Hub

Understanding the naming convention for extension points

Component names for extension points use the following notation:

AllIssues
Includes all issues from the Next-Best-Action Designer taxonomy.
AllGroups
Includes all groups within one or all issues from the Next-Best-Action Designer taxonomy.
<Issue>
The name of an issue in the Next-Best-Action Designer taxonomy.
<Group>
The name of a group in the Next-Best-Action Designer taxonomy.
<Hierarchy_Level>
Specific issues and groups from the Next-Best-Action Designer taxonomy. Not all of the below combinations are available for all strategies.
  • TopLevel - all groups within all issues
  • <Issue> - all groups within the issue
  • <Issue>_<Group> - a specific issue and group
  • <Issue>_AllGroups - all groups within the issue
  • AllIssues_AllGroups - all groups within all issues
Note: Since groups are individually defined for each issue, groups defined for different issues are distinct rules, even if they have the same name. Because of that, AllIssues_<Group> is not a valid combination.
<Context>
The name of a context entity from the Context Dictionary, for example Customer, Account, or Subscriber.
<Channel>
The name of a channel, for example Web, Email or SMS. Both built-in and custom channels are supported.
<Direction>
Inbound or outbound.
<Triggering Strategy>
Depending on the combination of issues and groups to be processed, and the method of initiation, for example, real-time container, outbound schedule, or event trigger, the Next-Best-Action Designer strategy can be invoked from the following strategies:
  • H_NBA_<Issue>
  • NBA_<Issue>
  • NBA_<Issue>_<Group>
  • NBA_TopLevel
  • Trigger_H_NBA_<Issue>
  • Trigger_NBA_<Issue>
  • Trigger_NBA_<Issue>_<Group>
  • Trigger_NBA_TopLevel
->
Indicates the calling strategy hierarchy for the parent strategy. Each successive strategy is called from the previous one in the list.
Note: Some extension points are referenced more than once, in which case they will have multiple parent strategies.

Extension points in a multilevel implementation

In a multilevel context implementation, the Trigger strategy will include embedded sub-strategies that iterate over each context instance within the parent context, e.g. for a telecommunications implementation this may be Device within Subscriber within Account, whilst for a financial implementation it may be Customer within Account.

The NBA Strategy Framework is invoked for separately for each such context, so that Subscriber context actions will be processed separately from Account context actions, etc.

This needs to be borne in mind when using the extension strategies that are subordinate to the NBA Strategy Framework, since only actions from a single context will be processed during execution. If any logic is required that spans action context - that is, requires the actions from different contexts to be in the same SR, then use one of the two FinalLimitsAndBundlingPreExt and FinalLimitsAndBundlingPostExt strategies that are invoked after all action contexts have been merged.

Required strategy extensions

Required extension points must always be configured.

Extension point strategy nameParent strategiesPurposeBusiness use case
AuthorizedContact

<Triggering Strategy>

<Triggering Strategy>-> FinalActionLimitsAndBundling-> BundlingSettingsYieldActions -> GetPrimaryContacts

In a multilevel context implementation, insert logic to only select primary context records that are authorized contacts. When executed from the triggering strategy, the property IsPrimaryContact will be set to true for each of these. Use this to designate contacts as being the preferred or authorized contacts within a parent entity such as Household or Account, e.g. head of household, or primary account holder.

IsPrimaryContact may be used in Engagement Policies to select actions only for these contacts, and the Communicate To property on the action form may be used to redirect actions to these contacts.

Optional strategy extensions

For extension points listed in this section, the strategy is empty, and you can configure it as needed to suit your requirements, or leave it blank.

Extension point strategy nameParent strategiesPurposeBusiness use case
NBA_<Issue>_<Group>_Ext

Various-> NBA_<Issue>_<Group>_AllActions

Apply any additional logic to all actions in the named <Issue> and <Group> after the Eligibility, Applicability and Suitability conditions have been evaluated. This logic is executed at the highest context level in the Context Dictionary, regardless of action context, and before the context specific engagement policies.When migrating to Next-Best-Action Designer, any existing issue or group-specific action eligibility strategies or proposition filters may be included here to augment the default proposition filters. This allows existing artifacts to be re-used and gradually phased out new engagement policies are built in Next-Best-Action Designer.

Typically an engagement policy created within Next-Best-Action Designer will not require any additional logic.

NBA_<Issue>_<Group>_<Context>_Ext

NBA_<Issue>_<Group>

-> NBA_<Issue>_<Group>_<Context>

<Triggering Strategy>

-> NBA_TopLevel_<Primary Context>-> H_NBA_<Issue>_<Context>-> NBA_<Issue>_<Group>_<Context>

H_NBA_<Issue>

-> H_NBA_<Issue>_<Context> -> NBA_<Issue>_<Group>_<Context>
Apply any additional logic to all actions for the named <Context> in the named <Issue> and <Group> after the Eligibility, Applicability and Suitability conditions have been evaluated. This logic is executed only in the context of the named <Context>, but not the primary context.When migrating to Next-Best-Action Designer, any existing issue or group-specific action eligibility strategies or proposition filters may be included here to augment the default proposition filters. This allows existing artifacts to be re-used and gradually phased out as new engagement policies are built in Next-Best-Action Designer. Typically an engagement policy created within Next-Best-Action Designer will not require any additional logic.
NBA_AllIssues_AllGroups_Ext

Various-> NBA_AllIssues_AllGroups_<Context>

Apply any additional logic to all actions in all issue and group combinations after the Eligibility, Applicability and Suitability conditions have been evaluated. The same logic is executed for actions of any context level based on the context of the parent strategy, so if action context is significant, this needs to be accounted for within the logic.When migrating to Next-Best-Action Designer, any existing generic action eligibility strategies (that apply to all issues and groups) may be included here to augment the default proposition filters. This allows existing artifacts to be re-used and gradually phased out new engagement policies are built in Next-Best-Action Designer.

Typically an engagement policy created within Next-Best-Action Designer will not require any additional logic.

NBA Pre-Process Extension Point

Various-> NBA Strategy Framework

Logic can be inserted at the start of the Next-Best-Action strategy framework before any other logic is executed. This is after all engagement policies and any of the above extensions have been executed, and actions from all issues, groups, and contexts have been merged.

This is a catch-all extension point to allow any global logic to be applied to all actions after the initial engagement policies have been evaluated.

This effectively achieves the same purpose as the NBA_AllIssues_AllGroups_Ext extension, except that it is executed only once after actions from all issues and groups have been merged, rather than separately for each issue or group.

Use this to augment action data - e.g. from one or more DDRs, or derive any calculated properties that may be required later in the Next-Best-Action Designer logic. However, note that if the data is not required as part of the scoring, treatment processing, arbitration or channel processing sections, then this may be better done later in the Next-Best-Action Framework after the number of actions has been reduced.

Create Eligible Channel Extension

<Triggering Strategy>-> NBA Strategy Framework -> Action Level Propensity -> Create Eligible Channels

Used for additional channel processing or validation. Note that this will be in addition to the default channel validation - it does not replace it, i.e. it is intended only to process channels that would otherwise not be selected by the default logic.The Create Eligible Channels strategy that calls this extension validates and assigns available default channels to actions. If additional channels need to be defined, it is recommended that these are added to the Other category to allow the default logic to also validate and assign these. However, if more granular control is needed for the additional channels than is provided by the default Other channel, then additional logic may included here. Use the logic in the Create Eligible Channels strategy as a template for building the extension logic.
ActionLevelPropensityExt

<Triggering Strategy>-> NBA Strategy Framework-> Action Level Propensity

Logic can be inserted after action scoring has occurred, for example, to include addition models or adjust the model propensity. Note that this extension is not executed for transactional actions.This extension is largely redundant for model related changes since the concept of modifiable Predictions was introduced and model related logic can be managed within these predictions.

However, this could be used to introduce A/B testing or Champion Challenger functionality at the action level if required.

OutboundPreferencesExtension

<Triggering Strategy>-> NBA Strategy Framework-> TreatmentsChannels-> OutboundChannels-> OutboundChannelPreferences

Addition logic can be inserted after the treatment data has been retrieved, but before treatment scoring is performed.
Note: An extension point is not available for Inbound channels.
This extension applies to all outbound channels except for Paid and is executed after treatments for all outbound channels have been merged.

It can be used to apply channel preferences or arbitration across channels, e.g. using an adaptive model or customer preferences to prioritize channels.

Note: This is not relevant to inbound channels, as only a single channel is ever present for an inbound interaction.
AIModelsExt

<Triggering Strategy>-> NBA Strategy Framework-> TreatmentsChannels-> TreatmentLevelPropensity-> PredictTreatmentPropensity

Logic can be inserted after treatment scoring has occurred, but prior to outbound model maturity processing, for example, to include addition models or adjust the model propensity.
Note: This extension is not executed for transactional actions.
This extension is largely redundant for model-related changes since the concept of modifiable predictions was introduced and model related logic can be managed within these predictions.

However, this could be used to introduce A/B testing or Champion Challenger functionality at the treatment level if required.

TreatmentLevelPropensityExt

<Triggering Strategy>-> NBA Strategy Framework-> TreatmentsChannels-> TreatmentLevelPropensity

Logic can be inserted after treatment scoring and outbound model maturity processing has occurred, for example, to include addition models or adjust the model propensity.
Note: This extension is not executed for transactional actions.
The only difference between this and the above extension point is that it executed after outbound model maturity has been evaluated, and so some immature actions may have been eliminated.
ControlGroupImpl

<Triggering Strategy>-> NBA Strategy Framework

Logic can be inserted to determine whether the contact is part of a custom control group. If yes, the additional InControlGroup extension strategy is executed instead of all of the prior next-best-action processing, including action imports and validation.Use this strategy to identify customers in universal control groups and to use a custom strategy InControlGroup (see below) to generate the output for such customers.
Note: Note that this could also be used to detect any other alternate behavior required for a customer that requires output other than that generated from the regular next-best-action processing.
InControlGroup

<Triggering Strategy>-> NBA Strategy Framework

This strategy is provided as an alternative action selection mechanism if the ControlGroupImpl extension strategy identifies the current contact (customer) as being in a control group.
Note: The External input option is disabled for this strategy, so it does not import any actions from the Next-Best-Action Designer framework and must generate any output required from the framework.
Used in conjunction with ControlGroupImpl above. Use this strategy to generate the output required for customers identified in the ControlGroupImpl strategy, e.g. in a universal control group, or requiring some other alternative processing.

For example, for a control group this could be a dummy action that will be persisted to Interaction History in order to identify the customer as being in the control group, but that is not emitted to the channel.

It could also include an alternative set of actions and treatments required by a specific group of customers.

CalculateValueExtension

<Triggering Strategy>-> NBA Strategy Framework-> Arbitration-> Calculate Business Value

This strategy can be modified using the Action value feature from the Arbitration tab in Next-Best-Action Designer. It allows the Action Value property to be calculated for all actions, where V = Value in the P x C x V x L calculation..Typically, the Value property assigned to the action would be used as V in the P x C x V x L arbitration calculation. Use this strategy to adjust or derive the Value property based on customer or other Strategy Result properties.
QnAContextWeightingExt

<Triggering Strategy>-> NBA Strategy Framework-> Arbitration-> QnAContextWeighting

Add any QnA-related logic in this extension strategy to update the .ContextWeight property. Changes should be additive to this property, that is, they should take the form of ContextWeight + myContextWeight.This extension is intended to cater for any Question and Answer data obtained from inbound interaction dialogs where the responses may be used to adjust the context weighting.
Process<Direction><Channel>Channel

<Triggering Strategy>-> NBA Strategy Framework-> ChannelProcessing -> OutboundChannelProcessing

For outbound channels only.
Note: For channels that are exclusively outbound (for example, Email, SMS) the <Direction> component is omitted from the strategy name.
These strategies allow for outbound channel specific logic to be applied prior to the default channel processing performed by the TopOfferOrBundleForOutbound strategy.
It is understood that the generic default logic for all outbound channels provided in the TopOfferOrBundleForOutbound strategy may not fully meet local requirements, and so these strategies are provided to augment the default functionality.

The Action Limits DDR described in Setting Limits on the number of Actions will obviate any need to directly set output limits in these strategies, but these extension points can be used for applying custom logic or setting additional channel specific properties for output.

<Channel>InboundChannelExt

<Triggering Strategy>-> NBA Strategy Framework-> ChannelProcessing -> InboudChannelProcessing-> <Channel>InboundChannel

For inbound Assisted and Other channels only.

These strategies allow for additional logic to be applied after all default channel processing has occurred.
The Action Limits DDR described in Setting Limits on the number of Actions will obviate any need to directly set output limits for these channels, but these extension points can be used for applying custom logic or setting additional channel specific properties for output.
ContactPolicyExtension

<Triggering Strategy>-> NBA Strategy Framework-> ChannelProcessing -> OutboundChannelProcessing-> ProcessOutboundChannels-> TopOfferOrBundleForOutbound-> OutboundLimits

Allows for addition contact policy rules to be applied after the default rules have been executed.
Note: The Contact Policy is not applied to transactional actions.
The default Contact Policy definitions should cater for most requirements, but any local policies than are not possible using default functionality may be included here.
Note: The default rules cannot be replaced, but are augmented by any custom logic.
FallbackNBAStrategy

<Triggering Strategy>-> NBA Strategy Framework

This strategy is provided as an alternative action selection mechanism if the Next-Best-Action active switch in the Next-Best-Action Designer Settings DDR is set to false - in other words, if Next-Best-Action is turned off.
Note: The External input option is disabled for this strategy, so it does not import any actions from the Next-Best-Action Designer framework and must generate any output required from the framework.
Use this to provide a default set of actions and treatments in the event that the regular next-best-action strategies need to be disabled temporarily.
NBAPostProcessExtension

<Triggering Strategy>-> NBA Strategy Framework

This is the final stage of the Next-Best-Action Strategy Framework, after all context level action processing has occurred and before actions from different contexts are merged.While the channel extension strategies described above are useful for implementing any channel specific custom logic, this extension point allows additional logic to be included that spans all channels.

However, note that this will only be applied to actions from a single context at a time - if actions from multiple contexts need to be considered, then use one of the Final Limits extension points described below.

FinalLimitsAndBundlingPreExt

<Triggering Strategy>-> FinalActionLimitsAndBundling

This is executed before actions for all contexts have been processed by the Next-Best-Action Designer framework, and before any outbound bundling or final action limits are imposed.There is no specific use case for this extension point, but it is provided to allow for any additional logic to be inserted after all actions for all contexts have been processed and merged and before final limits and bundling processing is performed.
<Channel>ChannelExt

<Triggering Strategy>-> FinalActionLimitsAndBundling-> Treatment Placements

For inbound Web and Mobile channels only.

These strategies allow for additional logic to be applied after all processing of default channels has occurred.

It is understood that the default logic for these channels may not fully meet local requirements, and so these strategies are provided to augment the default functionality.

The Action Limits and Final Action Limits DDRs described in Setting Limits on the number of Actions will obviate any need to directly set output limits in these strategies, but these extension points can be used for applying custom logic or setting additional channel specific properties for output.

FinalLimitsAndBundlingPostExt

<Triggering Strategy>-> FinalActionLimitsAndBundling

This is executed before actions for all contexts have been processed by the Next-Best-Action Designer framework, and before any outbound bundling or final action limits are imposed. It is the final stage of the Next-Best-Action Designer framework strategies.There is no specific use case for this extension point, but it is provided to allow for any additional logic to be inserted after all Next-Best-Action Designer logic has been applied for all actions for all contexts

Modifiable strategy extensions

Extension points listed in this section are fully functional out of the box, but you can still modify the logic if it is critically important to your business needs.

Extension point strategy nameParent strategiesPurposeBusiness use case
JourneyWeightAndPredictorsExt

<Triggering Strategy>-> NBA Strategy Framework-> Customer Journeys-> Journey Weight And Predictors

Use this strategy to include any custom logic for setting journey properties or calculating journey weights.Only use this if the default weight calculations do not suit your needs, or if you want to prepare additional journey related predictors for the models. Bear in mind that any additional model predictors will also need to be included as parameters for the models and so will require the models to be updated, and the generated strategies that call them.
Handle Model Maturity

<Triggering Strategy>-> NBA Strategy Framework-> Action Level Propensity -> Predict Action Propensity

<Triggering Strategy>-> NBA Strategy Framework-> TreatmentsChannels -> TreatmentLevelPropensity-> PredictTreatmentPropensity

The values in the Model Maturity Threshold and Population Percentage Set Property shapes may be changed to suit local requirements. The default values are 200 and 2% respectively.

Model Maturity Threshold is the number of positive responses above which the model is deemed to be mature.

Population Percentage is the initial percentage of the population that will receive actions for which the models are immature. This will increase towards 100% as the number of positive responses approaches the Model Maturity Threshold.

Only modify this strategy if the default values are not suitable.
<Channel>ChannelStrategy

<Triggering Strategy>-> NBA Strategy Framework-> TreatmentsChannels-> OutboundChannels

<Triggering Strategy>-> NBA Strategy Framework-> TreatmentsChannels-> InboundChannels

These strategies may need to be updated if additional treatment metadata needs to be added to the treatment definitions, for example if the <Channel>Treatments Decision Data Rule has been extended.These are default strategies that assign treatments to actions separately for each channel. They are not extensions as such, but are able to be modified to suit local requirements.

If additional properties need to be added to treatment definitions, then these strategies may be updated to accomplish this.

Optional DDR extension points

For extension points listed in this section, the Decision Data rule is empty, and you can configure it as needed to suit your requirements, or leave it blank.

For more information about these extension points, see Additional NBA Strategy framework components.

Extension point Decision Data rulesParent strategiesPurposeBusiness use case
ModelPropensityThresholds

<Triggering Strategy>-> NBA Strategy Framework -> Action Level Propensity -> PredictActionPropensity

<Triggering Strategy>-> NBA Strategy Framework -> TreatmentsChannels -> TreatmentLevelPropensity-> PredictTreatmentPropensity

Used to set lower limits on the propensity generated by the adaptive models at the Direction, Channel, Issue, Group, Action, or Treatment levels.
Note: The Treatment level is only referenced if the propensity calculation is set to Best treatment.
This DDR only needs to be used if there is a requirement to set minimum propensity values above which action propensities need to be in order to be emitted. Otherwise it may be left empty.
ActionLimits

<Triggering Strategy>-> NBA Strategy Framework -> ChannelProcessing -> OutboundChannelProcessing-> ProcessOutboundChannels-> TopOfferOrBundleForOutbound

<Triggering Strategy>-> NBA Strategy Framework -> ChannelProcessing -> InboundChannelProcessing-> AssistedInboundChannel OtherInboundChannelProcessWebChannelProcessMobileChannel

Used to set limits on the number of actions that can be emitted for each action context, limits can be set at the Direction and Channel levels. These limits are processed after arbitration, and before outbound contact policies are applied.

For inbound channels, they are only processed for the Web and Mobile channels if Channel treatment processing is disabled.

This DDR only needs to be utilized if there's a requirement to set limits on the number of actions that may be emitted per Direction, Channel and Context other than the defaults. Otherwise it may be left empty.
ArbitrationInfluencers

<Triggering Strategy>-> NBA Strategy Framework-> Arbitration-> ApplyInfluencers

Used to define Arbitration Influencer Contact Policies that use the insights gained from the outcome of presenting an action to influence the arbitration of the same action - or one or more related actions - at some future interaction.This DDR only needs to be utilized if there's a requirement to upweight some actions in future interactions based on a prior response to an action.

For example, during an interaction with a call center agent, if a customer expresses an interest in an offer, but needs to drop off the call due to other commitments, the outcome could be recorded as Maybe-Later. On the next interaction with the same customer it may be prudent to boost the chances of that same action - or some related actions – being selected as the next best action, on the assumption that the customer may still be interested and have a higher likelihood to accept the follow-up action based on their initial Maybe-Later response.

OutputBundlingSettings

<Triggering Strategy>-> FinalActionLimitsAndBundling-> BundlingSettingsYieldActions

Used to set the bundling output options (BundleOutputType, SinglePrimary and pyDeliverOffline) by Direction and Channel, which are mainly used for outbound processing. These settings are applied after actions for all contexts have been processed by the Next-Best-Action Designer framework and prior to evaluating the final action limits.This DDR only needs to be utilized if there is a requirement to change the default bundling and output settings. Otherwise it may be left empty.
FinalActionLimits

<Triggering Strategy>-> FinalActionLimitsAndBundling-> ApplyFinalActionLimits

Used to set limits on the number of actions that can be emitted for each contact or for the interaction as a whole. Limits can be set at the Direction, Channel and Action Context levels, and the limits for action contexts can be combined.This DDR only needs to be utilized if there is a requirement to set limits on the number of actions that may be emitted per Direction, Channel, Context and Contact other than the defaults. Otherwise it may be left empty.

Modifiable DDR extension points

Extension points listed in this section are fully functional out of the box, but you can still modify the logic if it is critically important to your business needs.
Extension point Decision Data rulesParent strategiesPurposeBusiness use case
<Channel>Treatments<Channel>ChannelStrategyAdditional treatment properties may be added to these Decision Data rules.
Note: You must update the parent strategies to map the new data in the associated Data Join.
See the use case for <Channel>ChannelStrategy in List of extension points in strategies.

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us