Published Release Notes

Editable list of build-on application features

Pega Platform™ now provides you with an option to edit the list of features in your application stack. Now you can define the order of the features to generate application documentation that lists the features by their priorities instead of the time of creation. For example, you can reorder the features when you want to communicate to your stakeholders which elements are top priorities.

For more information, see Learning about feature order.

Anypicker control in a condition builder

The condition builder now uses the Anypicker control to categorize the entities, such as fields or when conditions, that your application compares at run time. As a result, you can create conditions in a simplified and accelerated way. You can also select fields that are up to four levels deep within field groups.

For more information, see Create conditions faster with an Anypicker control (8.4), Adding an Anypicker control, Defining conditions in the condition builder.

Updated default dynamic system setting for requestor pools

Clients can now enable or disable requestor pools for processing service requests using a new dynamic system setting called EnableRequestorPools with Pega-IntegrationEngine as the owning rulest. Previously, all deployments utilized requestor pools to improve service processing response efficiency; requestor pools eliminated overhead by automatically returning a requestor to the pool after it fulfills a service request. Starting in Pega Platform 8.4, requestor pools are disabled in Client-managed cloud deployments, since these deployments use autoscaling to handle service request traffic. Enabling requestor pools in Kubernetes environments is not recommended, because they can inhibit the default autoscaling settings in the environment.

Requestor pools remain enabled by default in Pega Cloud and on-premises environments.

To help clients navigate this change, Pega has updated its best practice guidance for configuring requestor pools. For an overview, see Requestor pooling for services. For guidance on the use of requestor pools in your application, see the EnableRequestorPools entry in Dynamic system settings data instances.

Upgrade impact

Requestor pools are disabled by default in Pega Platform 8.4 in client-managed cloud deployments. Clients who deployed previous versions of Pega Platform on a Kubernetes environment and who upgrade to Pega Platform 8.4 could see that their services behave differently.

What steps are required to update the application to be compatible with this change?

If clients that are deployed in a Client-managed cloud environment need to configure their services to use requestor pools and they understand how to configure requestor pools for their optimized use, these clients can re-enable requestor pools. Clients should review the best practice for configuring requestor pools before they re-enable requestor pools. To re-enable requestor pools, you modify the EnableRequestorPools setting in the Pega-IntegrationEngine Owning ruleset from “disabled” to Enabled [no value]. For details, see Editing a dynamic system setting.

Condition builder enhancements

To enhance the precision of condition builder in both App Studio and Dev Studio, the new instances include comparator helps you specify the number of field group and field group list instances to which a when rule applies. In addition, a search option that returns results on keypress helps you easily look for existing values.

For more information, see Create conditions in an enhanced condition builder (8.5), Defining conditions in the condition builder.

Business logic-based routing cards enhancements

To ensure that the sequence of business logic-based routing cards conforms to your business requirements, you now have the option to change the order of the cards. For easier navigation across multiple routing cards, the system automatically collapses the cards for you, and you can then easily expand the cards that you need to display.

For more information, see Navigate easier across business logic-based routing cards (8.5), Assigning users automatically at run time.

Support for nested Declare Trigger rules

Pega Platform™ now supports nested Declare Trigger rules so that you can conveniently create correlations between actions in your case types. Declare Triggers rules invoke an action when a specified event takes place in a case type. You can now design more complex scenarios faster by nesting more Declare Trigger rules that work in the context of running another Declare Trigger rule. For example, when a case participant changes a postal code in their personal details, a Declare Trigger rule runs and a respective customer service representative (CSR) receives an email. After the CSR receives the email, a nested Declare Trigger rule runs and your application creates a document with the updated personal details and attaches it to the case.

For more information, see Develop applications faster with nested Declare Trigger rules (8.5), Declare Trigger rules.

Optimized data schema upgrade

Several improvements have been made to optimize the speed of the data schema upgrade to help you experience minimal downtime during upgrade to Pega Platform 8.5™. The data schema upgrade process optimizations include the following improvements:

• Optimized database index creation during upgrade
• Optimized synchronization process to detect duplicate rules during the application import process
• A new upgrade setting for Pega Cloud® Services operators that reduces the time to upgrade clients that run large Pega applications, such as the CRM Suite

For more information, see Limit upgrade downtime with data schema upgrade improvements (8.5).

Support for validations in Declare Expression rules

Pega Platform™ now correctly evaluates validations on target properties in Declare Expression rules. As a result, any validations defined on properties that have Declare Expression rules in previous releases, now work correctly. 

Upgrade impact

Any unintended validations on properties that have configured Declare Expression rules, both default and user-defined, might cause issues in an application upon saving work objects and data objects that refer to Declare Expression rules.

What steps are required to update the application to be compatible with this change? 

If you experience issues when saving objects, debug your application by setting the declareexp/target/validation/disable dynamic system setting to true. If your application works correctly after the change, it means that validations on Declare Expressions cause the issues. For your application to work correctly, analyze the log files and remove any unintended validations.

For more information, see Declare Expression rules.