Table of Contents

Setting Limits on the number of Actions


Only available versions of this content are shown in the dropdown

Action Limits and Final Action Limits are two features that can be used to control the number of actions delivered to contacts. These features have a similar impact, but are implemented in different stages of the Next-Best-Action Strategy Framework as described below along with some other related concepts.

Context entity
An entity on which Next-Best-Action decisions can be made, e.g. 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:
  • Retail Banking:
    • Customer – can have multiple Accounts
      • Account – one per card or account
  • Telecommunications:
    • Account – can have multiple Subscribers
      • Subscriber – one for each phone number, can have multiple Devices
        • Device, for example, phone, tablet, watch
  • Healthcare:
    • Policy – can have multiple Members
      • Member – can have multiple Claims
        • Claim
Primary Context entity
The entity to which all actions will be communicated, i.e. 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 / 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 configuredby the user during the implementation phase to only selectPrimary Contacts for an account / relationship.If it is possible to select multiple such contacts, they should be prioritized so that the preferred contact is returned first.
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, e.g. 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.
This is a setting within the Final Action Limits DDR that allows a limit to be shared across a combination of Action Contexts.
This is a setting within the Final Action Limits DDR that allows a limit to beapplied separately to each contact,or across all contacts.
Action Limits

This is a Data Decision Rule (DDR) containing settings that are evaluated separately for each action context and for each contact (i.e. a primary context, such as a Subscriber or Customer) after arbitration has occurred. This means that although a CombineContexts property is available for this feature, it has no effect, since each action context is evaluated independently from any other.

Furthermore, all outbound channels are evaluated as a combined group (within Action Context and contact), and so a limit can be applied across all outbound channels, whereas for inbound channels, only a single channel willbe processed during any interaction.

Final Action Limits

This is a Data Decision Rule (DDR) containing settings that are evaluated after Action Limits have been applied, and after actions for all contexts and all contacts have been arbitrated and merged. This is the final process that occurs in the NBA framework prior to output bundling.

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). Just to be clear, a 'contact' is an instance of the primary context entity with its own unique pySubjectID.

  • Action Limits Use Cases

    The Action Limits use cases below are examples of how these two features can be utilized. These examples use the telecommunications paradigm of Device within Subscriber within Account.

Did you find this content helpful?

Have a question? Get answers now.

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