The extension strategy OutboundPreferencesExtension is available to implement any customer preference filtering, for example, that the customer does not wish to be contacted through SMS. This is a placeholder strategy and needs to be implemented if you wish to take advantage of this.

This strategy only applies if the primary direction is Outbound or if the direction has not been specified (which implies it is a batch run). The individual channels must also be active and enabled on each action.

All of the individual channel sub-strategies – other than Paid – use the same method for assigning treatments to actions and augmenting the treatment data. They link actions with their channel specific treatments from the <Channel>TreatmentsJoin DDR (where <Channel> represents the name of the channel). As a result, the pyTreatment value is set on the action; if there are multiple treatments a separate action page is generated for each treatment. The pyTreatment property can be used in the action flow canvas to dynamically set the treatment name. This allows you to define a template flow and apply it to the action.

Additional Treatment properties are obtained from the <Channel>Treatments DDR and joined to the actions, and then Apply <Channel> Treatment Eligibility calls the channel treatment eligibility rules sub-strategy.

These strategies may be overtaken and customized for local requirements if required, and the <Channel>Treatments DDR may be extended to augment the treatment data. For more information, see Managing Decision Data rules in Pega Customer Decision Hub.

The individual channel strategies are described in more detail below.

Email, SMS and Push channel strategies

The EmailChannel strategy links actions with email treatments from the EmailTreatmentsJoin DDR. As a result, the pyTreatment value is set on the action. The pyTreatment property can be used in the action flow canvas to dynamically set the treatment name. This allows you to define a template flow and apply it to the action.

The SMS and Push channel strategies follow the same pattern.

Other treatment strategy

This strategy performs the basic logic for assigning treatments, augmenting treatment data and evaluating treatment eligibility, but with some minor additions.

Some of the individual metadata values that are defined at the treatment level will override their action-level equivalents. Also, since this strategy is used for both Outbound and Inbound interactions, the join conditions for the DDR are slightly different for each and are selected via the Switch join based on direction Switch rule.

Assisted channel strategy

This strategy performs the basic logic for assigning treatments, augmenting treatment data and evaluating treatment eligibility, but with some minor additions.

This strategy is used for both Outbound and Inbound interactions, and pyDirection on the Assist Treatments DDR is defaulted to Inbound if not already set. Also, some of the individual metadata values that are defined at the treatment level will override their action-level equivalents.

Paid channel strategy

This strategy is an empty canvas and allows you to implement additional channel-specific logic as required.

Outbound Channel Extension

This sub-strategy is a placeholder strategy to implement any customer preferences. It contains a single extension point sub-strategy OutboundPreferencesExtension which contains only a blank canvas.