Skip to main content

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.

Context Dictionary in the CDH-Rules ruleset

Caution: Changing the primary context is destructive and invalidates all Next-Best-Action Designer and outbound artifacts, and requires you to regenerate the artifacts.

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

List of pyDictionaries

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.

Generated product file after wizard run

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.

Tip: As a best practice, set the ContextName property to the top context. Doing so makes all data for that context available during the strategy execution.
Caution: When a service call occurs for a specific context entity that is not the top context, only the data for that specific context and its parent context are available at run time. For example, making a service call with ContextName set to a specific subscriber on an account that has multiple subscribers does not retrieve all subscribers on the account. Only the data regarding the specific subscriber and account is available.

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.

Customer and account context

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.

Figure explaining the SingleCustomer dataflow

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.

Figure explaining the SingleAccount dataflow

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.

Context view in the Action form for customer

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.

Context view in the Action form for account

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

Context view in the engagement policy

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.

Selecting the intended recipient

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.

Authorized contact sub strategy

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.

TriggerNBAToplevel strategy with the context values


This Topic is available in the following Module:

If you are having problems with your training, please review the Pega Academy Support FAQs.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega Academy has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice