The Context Dictionary

In Pega Customer Decision Hub™, you use the Context Dictionary to control how to present next best actions to various levels of customer contacts, such as a head of household, account owner, or device owner. The ability to present an action to different levels is called multilevel decisioning.

The levels of customer contacts are the contexts and act as different audiences with which you communicate in different ways. For example, you can offer an account owner a family mobile data plan that applies to the whole account and send new phone offers to individual household members who qualify for them.

The Context Dictionary defines the context in which Next-Best-Action Designer communicates actions to customers. Next-Best-Action Designer bases its decisions on communication with an individual (for example, a customer, subscriber, or member) and not with more abstract entities such as an account or policy. However, the actions might be relevant for other entities in the hierarchy and so are assigned to the intended context. For example, you can offer a customer a credit line increase on a specific credit card account or service on a mortgage account.

With the Context Dictionary, you define context entities, the primary context and the relationship between these entities. You can access the Context Dictionary through the Settings > Context Dictionary menu in App Studio. Every Customer Decision Hub application has its own unique Context dictionary.

Any entity on which the next-best-action decisions can be made is called a Context Entity. You cannot define entities that are not associated with actions, such as behavioral data or purchase data, as contexts. These entities are associated data that you configure in the Customer Profile Designer.

The defined context entities always have a parent-child relationship. You cannot define multiple parent-child structures or have a stand-alone context entity without an associated parent entity.

During the setup process, if you apply an industry template, Customer Decision Hub automatically configures the Context Dictionary for you. Otherwise, the decisioning architects manually configure the context entities and the associations between these entities. Before generating the Context Dictionary, the system architects create all underlying data and class structures for the entities.

Generating the Context Dictionary is typically a one-time task during the initial phase of any implementation. As a best practice, make a thorough analysis of the structure of the entities. Unless a new entity becomes available, which is an uncommon use case, you do not need to regenerate the Context Dictionary. Generate the Context Dictionary in the development environment only. Do not configure the Context Dictionary in higher environments such as staging, business operations, or production environments. When generating the Context Dictionary manually, you might decide to override existing rules.

As a best practice, always generate the Context Dictionary in the Rules ruleset of the implementation application and always use Database as the context storage. This setting indicates where the data for each entity resides, either in a relational database table or decision data store such as Cassandra. The second option Decision data store should not be selected except in unique circumstances.

The settings for each context in the Context Dictionary are stored in the corresponding pyDictionary decision data rules.

After you create the Context Dictionary, the Customer Decision Hub application generates various artifacts in the background such as properties, data flows, data sets, Next-Best-Action Designer framework strategies, adaptive models, and a product rule. You can access the product rule that contains all the generated rules directly from the Audit log of the Context Dictionary or by browsing the product rules (name_of_your_application_ContextGeneratedRules) in your application.

For each context entity definition in the Context Dictionary, a data flow is created in the appropriate class (Single<ContextName>Data) by using the defined associations. These data flows construct the data object that is necessary to make the next best action for that context. When calling the next-best-action real-time container, the ContextName in the service payload determines the context in which the next-best-action strategy runs. The value in the Context Name triggers the corresponding data flow.

Take a closer look at the following financial services example. The Context Dictionary uses the customer as the primary context, and the account is a context entity. Each context has a unique identifier (CustomerID for the customer context and AccountID for the account context). A customer might have multiple accounts (1:n) such as credit cards, mortgages, and investments in the bank.

The container call uses the ContextName to map to the correct context identifier: CustomerID or AccountID. Then, the data flows use this identifier to construct the data for that context.

In the below sample record, Customer1 has two accounts: Account1 and Account2.

When the container service is called for the Customer context, the call triggers the SingleCustomerData data flow to build the customer object. In this case, the customer data and account data for each account is available at run time.

When the container service is called for the Account context, the call triggers the SingleAccountData data flow to build the customer object. In this case, only data for that specific account and the customer data are available at run time. So, in circumstances where the customer has multiple accounts, only a single account is available during run time.

The defined context values in the Context Dictionary are automatically reflected in the forms of the action in Next-Best-Action Designer. Every action requires an action context.

In the following example, if the action context is Customer, then all customer and account data is available when Customer Decision Hub evaluates the eligibility of the action.

If the action context is Account, the system evaluates the conditions for each account of the customer individually. As a result, this action might qualify for multiple accounts that the customer owns. Customer Decision Hub then prioritizes all qualifying actions and determines the next best action for the customer.

The actions that are assigned to each context are automatically categorized into corresponding contexts on the Engagement policy tab of Next-Best-Action Designer.

In cases where the primary context is not the top context, such as a telecommunications example where an account (defined as the top context) has multiple subscribers (defined as the primary context), you can choose the intended recipient of the communication. You configure the communication recipient on the Engagement policy tab of the action rules; the value determines which contact or contacts receive the communication in a multilevel context dictionary configuration. The communication can be made with the original contact, redirected to the primary contact, or made with both the original and the primary contact.

To use this functionality, you configure the AuthorizedContact strategy and filter only the authorized contact. For more information, see Setting Output Bundling and Primary Contact options.

To learn more about the next-best-action framework and understand how the strategies are executed for the primary context and other contexts, see Trigger strategies.