Service and data health limits for Pega Customer Decision Hub on Pega Cloud
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.
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:
Service health limits
|Maximum number of outbound schedules||7||1|
|Maximum number of static customer profile attributes||500||250|
|Maximum number of calculated customer behavior aggregations||200||100|
|Maximum number of predictors fed to adaptive model||700||500|
|Maximum number of outbound runs per day||10||1|
|Maximum number of actions||2,500||1,000|
|Maximum number of treatments per channel||2,500||1,000|
|Maximum number of treatments across all actions||5,000||2,500|
|Maximum number of treatments for any single action||5||5|
|Maximum number of actions within an issue and group||250||100|
|Maximum number of groups within an issue||25||5|
|Maximum number of issues||25||5|
|Maximum number of attributes returned for an action||75||25|
|Maximum number of criteria in any single engagement policy||10||5|
|Maximum amount of context dictionary associated data entities||5||3|
|Maximum number of interaction history summaries||10||5|
|Maximum number of concurrent simulations in the Business Operations Environment (BOE)||1||1|
|Maximum number of concurrent users in BOE||50||Not 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 limits||Retention period||Can be increased||Export|
|Interaction history (cloud file storage)||180 days||No||SFTP|
|Interaction history (cloud data storage)||90 days||Yes||Not available|
|Maximum adaptive delayed learning time period||30 days||Yes||Not applicable|
|Decision history (cloud file storage)||180 days||Yes||SFTP|
- 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.
Previous topic Reference Next topic Adding new response outcomes