Paid actions are excluded from the Action & Treatment processing as they are passed through directly to the output.

Two extension points are provided: Final Limits and Bundling Pre Extension, and Final Limits and Bundling Post Extension for adding custom functionality before and after the main processing respectively.

For a detailed description of the logic, refer to the annotations on the strategy.

Bundling Settings & Yield Actions strategy

This strategy imports bundling settings from the Output Bundling Settings DDR and matches them to Actions by Direction, Channel and the pyDeliverOffline setting.

It also interprets the action CommunicateTo property (YieldToOriginal, YieldToAll, or YieldToPrimary) and reassigns or propagates actions to other Subject IDs as required.

Further details on the Output Bundling Settings DDR and the action CommunicateTo property can be found in Setting Output Bundling and Primary Contact Options.

For a detailed description of the logic, refer to the annotations on the strategy.

Get Primary Contacts strategy

This strategy is generated based on the Context Dictionary configuration to call the Authorized Contact strategy from the primary context. In cases where there may be more than one authorized contact, and where one contact should take precedence over the others, the strategy should be overtaken and a Prioritize shape included prior to the exit point to ensure that the most important contact is output first.

Apply Final Action Limits strategy

This strategy is ostensibly the same as the Apply Action Limits Strategy already described, with just the following differences:

• It uses the Final Action Limits DDR instead of the Action Limits DDR.
• The initial Group By adds SubjectID and OriginalSubjectID, and keeps these plus IsPrimaryContact, because the LimitByContact option allows limits to be applied at the subject level or over all subjects.
• The final Data Join adds SubjectID and OriginalSubjectID in order to allow for the LimitByContact option.
• There is no final Group By shape immediately prior to exiting, since any required treatment processing (other than Web or Mobile) will have already been performed.

Treatment Placements strategy

The Treatment Placements strategy assigns Treatments to Placement tags for the Web and Mobile Channels based on the placement type list provided in the container call, or defaults provided in the Page Placements DDR.

The goal of the strategy is to process required placements in order - either the order in which they are specified in the call, or by their ascending rank in the Page Placements DDR - and to allocate a treatment to each successive placement in descending priority order based on its placement type.

The logic is quite complex due to the requirement that once an action's treatment has been allocated to a placement, no other treatment from that action may be allocated to any other placements. An Iteration shape is used to accomplish this recursive behavior.

For a detailed description of the logic, refer to the annotations on the strategy.

Get Output Bundling Actions strategy

This strategy imports the bundle action definitions to be used for bundling output for each channel. Note that separate definitions can exist for Offline as well as Online output processing.

It uses the standard Next-Best-Action Designer framework strategies to assign active and eligible channels and treatments, and then uses a Group By to ensure there's only a single Treatment per channel.

ImportOutputBundlingActions strategy

This strategy is provided as a template to be updated as per the implementation requirements.

Insert the proposition import shapes for the parent bundle action to be used for each inbound and outbound channel. This could be a single shape that imports all of such actions from a single issue and group, or a separate shape for each action, or a combination thereof.

Separate bundle parents may be used for offline delivery or otherwise, simply by connecting the proposition import shapes to the Deliver Offline or Deliver Live shape. If offline delivery is not required for a channel, there is no need to connect any action for that channel to the Deliver Offline shape.

No logic other than the proposition import shapes and the Deliver Offline & Deliver Live shapes should be included in this strategy since the strategy is expected to be replaced in a future release.