Skip to main content


         This documentation site is for previous versions. Visit our new documentation site for current releases.      
 

Service and data health limits for Pega Customer Decision Hub on Pega Cloud

Updated on September 15, 2022

This content applies only to Pega Cloud environments

Pega Customer Decision Hub deployed in Pega Cloud has limits in place that constrain certain elements of the service and its use to ensure high quality of service for your team.

Pega Customer Decision Hub limits fall into two categories:

  • Limits on the duration that data is persisted.
  • Limits that define how much or how many of a certain solution element you can configure at design time or run at runtime.

All limits have default values. Where possible, you can increase some limits by opening a support request through My Support Portal.

Note:

Not all limits are enforced through hard caps, as noted in the descriptions of the individual limits. However, as a general rule, to avoid potential service impact, you should view them as hard limits, and only exceed them after careful consideration. These are organization-wide limits, not per-application. Pega currently does not support multiple Pega Customer Decision Hub applications, but this support is planned for the future.

During the normal course of utilization most systems do not exceed the service health limits defined below:

Pega Customer Decision Hub

Service health limits

DescriptionLimitBest practice
Maximum number of outbound schedules71
Maximum number of static customer profile attributes500250
Maximum number of calculated customer behavior aggregations200100
Maximum number of predictors fed to adaptive model700500
Maximum number of outbound runs per day101
Maximum number of actions2,5001,000
Maximum number of treatments per channel2,5001,000
Maximum number of treatments across all actions5,0002,500
Maximum number of treatments for any single action55
Maximum number of actions within an issue and group250100
Maximum number of groups within an issue255
Maximum number of issues255
Maximum number of attributes returned for an action7525
Maximum number of criteria in any single engagement policy105
Maximum amount of context dictionary associated data entities53
Maximum number of interaction history summaries105
Maximum number of concurrent simulations in the Business Operations Environment (BOE)11
Maximum number of concurrent users in BOE50Not applicable
Maximum number of outbound schedules
Controls the maximum number of outbound schedules that you can configure to run. Outbound schedules are processes that manage batch processing to iterate through your customer list and make outbound decisions for your customers (such as what emails or SMS messages to send). Each schedule uses intensive processing resources. Limiting this resource utilization keeps your system stable and healthy.
Maximum number of static customer profile attributes
Defines the maximum number of attributes (properties) that you can define for a given customer context entity. Exceeding the prescribed number leads to performance issues.
Maximum number of calculated customer behavior aggregations
Controls the maximum number of aggregates that you can build and maintain. Customer behavior aggregates are typically powerful predictive attributes of a customer. Each additional aggregate consumes computational resources that you must keep in check to maintain a healthy system.
Maximum number of predictors fed to adaptive model
Controls the maximum number of inputs to an adaptive model. Adaptive models learn from the data that you supply to them through predictor attributes. A system should consume as many attributes as possible of a customer profile in its learning process. However, too many predictors can affect the performance of a model and impact the SLA for returning a decision result. The upper limit is not enforced as a hard limit and you can exceed it after careful consideration.
Maximum number of outbound runs per day
Related to outbound schedules. Controls the number of outbound runs that a set of schedules starts within a day. To limit the utilization of resources, control the number of outbound runs.
Maximum number of actions
Controls the maximum number of actions that are defined and managed in the system, across all business issues and groups of the taxonomy. The system arbitrates the right action for a customer, across every possible action in the system. The more actions you add, the more arbitration decisions the system makes. This affects the SLA of returning a decision result and may impact the end-user experience if not controlled.
Maximum number of treatments per channel
Controls the maximum number of treatments that you can define for each specific channel. The standard channels include email, SMS, push, web, mobile, and call center. The next-best-action capability arbitrates across all of the treatments in a channel, so the more treatments you define, the more arbitration decisions that the system makes. This affects the SLA for returning a decision result and may impact the end-user experience if not controlled.
Maximum number of treatments across all actions
Controls the maximum number of treatments that you can define across all channels. When making a decision, the system joins eligible and relevant actions with eligible treatments, which expands the number of treatments that the system arbitrates. When making outbound decisions, the system arbitrates all outbound treatments (email, SMS, push). This affects the SLA for returning a decision result and may impact the end-user experience if not controlled.
Maximum number of treatments for any single action
Defines the maximum number of treatments that you can associate with a specific action. The treatment represents how the action is presented in the channel. A common configuration is to have variants, and let the AI pick the most appropriate variant based on the individual. Having multiple variants is good, but results in more arbitration decisions. Therefore, you should measure the number of treatments per action as this can affect the SLA for decision results.
Maximum number of actions within an issue and group
Defines the maximum number of actions that you can define for a specific issue and group. Each issue and group combination has its own decision data rule that stores the action metadata and is referenced by the strategy framework. There is a limit to the number of actions that you can store in a decision data rule before there is an impact on the SLA for the user experience and for the decision result if not controlled.
Maximum number of groups within an issue
Defines the maximum number of groups within an issue. To make decisions, Pega Customer Decision Hub imports and applies engagement policies that determine the set of actions that the application must arbitrate. Importing and filtering actions requires a specific amount of processing, so the more actions you add, the more processing the system requires to make a decision.
Maximum number of issues
Defines the maximum number of issues. To make decisions, Pega Customer Decision Hub imports and applies engagement policies that determine the set of actions that the application must arbitrate. Importing and filtering actions require a specific amount of processing, so the more actions you add, the more processing the system requires to make a decision.
Maximum number of attributes returned for an action
Defines the maximum number of strategy result properties for an action. A strategy result property provides details about the decision that the application has made. The system stores these properties as part of outbound schedule processing and delayed learning, and returns them as the response for inbound channels. The number of actions affects the amount of storage space required.
Maximum number of criteria in any single engagement policy
Defines the maximum number of individual conditions within the eligibility, applicability, or suitability policies. Overall, filtering out actions that are not eligible or applicable to a customer increases the speed of execution, because it reduces the number of actions that go through arbitration. This should be balanced with the complexity of engagement policies, especially custom When rules and referencing engagement strategies. These strategies should not reference interaction history.
Maximum amount of context dictionary associated data entities
Defines the number of entities that you can link to the contexts in the context dictionary to support pulling in additional data about an entity, such as a customer. An example of associated data linked to a customer entity is product holdings. The more entities you add, particularly one-to-many relationship entities, the more time the system requires to load this data for every decision that it makes. The load-time of such additional data impacts the overall SLA for a decision. Ensure that you link in only the critical data required to make a customer engagement decision.
Maximum number of interaction history summaries
Define the number of interaction history summaries that you can build. A good system design minimizes the number of unique interaction history summary rules configured. Every unique summary rule consumes real-time thread resources and memory, which can impact the overall health of the system. Calculating different summary outcomes within the same interaction history summary rule is a better practice than building multiple interaction history summaries. For example, to count the number of times a customer received an action in the last 10 days, and the number of times they received an action in the last 30 days, you only require one summary with 10-day and 30-day outcomes. Ensure that the design of your summaries follows best practices to minimize resource consumption and decision performance.
Maximum number of concurrent simulations in the Business Operations Environment (BOE)
Controls the number of simulations that can run concurrently in the BOE. Running simulations is a resource-intensive process as it collects extra information to support the analysis and present the results of the simulation. Teams operating in the BOE should consider scheduling time on a regular basis for ongoing simulation runs and ensure that unscheduled simulations do not overlap with regular simulation activities.
Maximum number of concurrent users in BOE
Defines the maximum number of concurrent users within the BOE to test configurations, request changes, review and approve revisions, and deploy these revisions to the Production environment.

Data health limits

Data retention limitsRetention periodCan be increasedExport
Interaction history (cloud file storage)180 daysNoSFTP
Interaction history (cloud data storage)90 daysYesNot available
Maximum adaptive delayed learning time period30 daysYesNot applicable
Decision history (cloud file storage)180 daysYesSFTP
Interaction history cloud file storage
Controls how many days of interaction history the system retains in the cloud file storage before purging this data. During this period, you can download the file to your own data storage for further analysis. By using Pega Customer Decision Hub you can also use this data to refresh and recalculate interaction history summaries. You can also search through interaction history when auditing a customer’s interactions.
Interaction history cloud data storage
Defines the number of days that the system stores interaction history in the short-term data storage before purging this data. You can use this storage for quick history lookups when interaction history summaries are behind in their calculations and must go to the short-term storage to synchronize their calculations.
Adaptive delayed learning time period
Controls the maximum time period that the system stores data for delayed learning of adaptive models. When a decision is made, as part of interacting with a customer, the system caches the data about how it made the decision while the system waits for a response from the customer (through the capture response mechanisms). The adaptive learning engine uses this data to improve its models. If the system receives a response outside of this time period, it captures the response in interaction history, but ignores it as part of improving the adaptive models.
Decision history files
Controls how many days of decision results the system retains in the cloud file storage before purging this data. During this period, you can download the file to your own data storage for further analysis. By using the Decision history tab in the Customer Profile Viewer, you can search through a customer’s historic decision results when auditing what decisions the system made for that customer.

Have a question? Get answers now.

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

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.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us