Trigger strategy
A trigger strategy is generated after you define a trigger within Next-Best-Action Designer and specify the business structure to apply. You cannot modify it directly. This strategy is referenced by a data flow, which is also generated and managed by the system.
Issue | Group | Trigger strategy name | Example |
All issues | All groups | Trigger_NBA_TopLevel | |
<Issue> | All groups | Trigger_H_NBA_<Issue> | Trigger_H_NBA_Acquisition |
<Issue> | <Group> | Trigger_NBA_<Issue>_<Group> | Trigger_H_NBA_Acquisition_Bundle |
The layout of the strategy depends on the configuration of the context dictionary. The following example shows an implementation of multiple Subscribers within an Account, where each Subscriber may have multiple Devices, for example, for a Communications application. Note that this example is for all issues and all groups.
The high-level logic flow is as follows:
- Import actions
- Post-action import extension
- Evaluate All Actions engagement policies for all action contexts
- Identify authorized contacts
- Split actions into a separate stream for each action context
- Evaluate the context level engagement policies
- Execute the next-best-action strategy framework separately for each context
- Merge all context streams
- Apply final action limits and bundling options
The arrangement of Switch rules around the All Actions engagement policy sub-strategies immediately after the action import is only required if the primary context is not the top-level context. Its purpose is to execute the engagement policy within the primary context if the Trigger strategy is being executed as part of a simulation, otherwise it is executed in the top-level context.
The Set Primary Contact shape sets the following properties:
- IsPrimaryContact - set to true if the contact is identified as an Authorized Contact
- OriginalSubjectID - set to pySubjectID
- OriginalContactID - set to pySubjectID
Previous topic Next-Best-Action Designer metadata Next topic Import Actions strategy