The Final Action Limits feature can be used to control the number of actions delivered to contacts.
Action Limits Concepts concepts
The Final Action Limits DDR along with some other related concepts is described below.
|Context entity||An entity on which next-best-action decisions can be made, for example, I want the next best action for a Customer, or the next best action for an Account.|
|Multilevel Context Dictionary||A configuration that has a hierarchy of context entities where actions may be
relevant for specific entities, for example:|
|Primary Context entity||The entity to which all actions will be communicated, that is, the entity representing the person with the contact details such as phone number, email address, etc. In the above examples, this would be the Customer, Subscriber or Member.|
|Primary Contact||An instance of the Primary Context entity that is authorized to make decisions on behalf of the account or relationship, also known as an Authorized Contact. For example, this may be a parent for a family phone plan or the primary member on a healthcare policy. Note that there may be more than one Authorized Contact for an account / relationship. The IsPrimaryContact property is set to true for any actions that are assigned to an authorized contact.|
|Authorized Contact||This is the name of a sub-strategy that is configured by the user during the implementation phase to only select Primary Contacts for an account or relationship.|
|Action Context||This is set on the action rule and is stored in the ActionContext property on the action. This is the name of the context entity for which the action is relevant, for example, a phone upgrade action would be for a Subscriber (or possibly Device), whereas a family data plan action would be for an Account, or a new credit card action would be for a Customer, whereas a credit line increase would be for an Account.|
|Final Action Limits||This is a Data Decision Rule (DDR) containing settings that are evaluated after
actions for all contexts and all contacts have been arbitrated and merged. This is
one of the final processes that occurs in the NBA framework prior to output
As such, limits can be applied to combinations of action contexts (using the CombineContexts setting), and to individual contacts, or across all contacts (using the LimitByContact setting).
Also, since all outbound channels are evaluated together, a limit
can be applied across all outbound channels, whereas for inbound channels, only a
single channel will be processed during any interaction.
Final Action Limits DDR
|pyLabel||A user-friendly name for an action limits setting.|
|pyDirection||Action limits are defined separately for Outbound and Inbound directions.|
|pyChannel||The channel (in combination with the action context) to which the Action Limit
is to be applied. Possible settings are described below.|
|pyIssue||The Issue (in combination with the action context) to which the Action Limit is to be applied. Blank indicates all issues.|
|pyGroup||Only used if pyIssue is not blank. The Group (in combination with the action context) to which the Action Limit is to be applied. Blank indicates all groups within the issue.|
|pyName||Not currently used.|
|CombineContexts||When set to true for multiple contexts within a channel specification, this allows a single limit to be applied to the combination of selected Action Contexts.|
|ActionContext||The Action Context to which the Action Limit is to be applied.|
|ActionLimit||The maximum number of actions allowed for the combination of Direction, Channel, Issue, Group and Action Context.|
|LimitByContact||Determines whether a limit applies to each contact or to the interaction as a
whole. Possible settings are described below.|
In the following example, if only Account context actions were available (i.e. had passed engagement policies, arbitration etc.), a maximum of 2 (Account-context) actions would be output, although if actions for both contexts were available, up to 3 actions (Account and / or Subscriber context) would be output.