Skip to main content

Published Release Notes

Find release notes for the selected Pega Version and Capability

Browse resolved issues for Platform releases.

This documentation is for non-current versions of Pega Platform. For current release notes, go here.

End of support for form-based rule forms in Pega 7.1.9

Valid from Pega Version 7.1.9

Rule forms that are configured to render as forms are no longer supported in Designer Studio or end-user applications. Form-based configurations are found on custom rule types that were created in earlier versions of Pega 7 and are characterized by pop-up windows that are rendered externally from Designer Studio.

Reconfigure Pega 7 applications that use such rule forms by using standard harnesses and sections.

  1. Open the class form.
  2. Click the Advanced tab.
  3. Select Harness from the Rule formmenu.
  4. Create a new harness and new sections that implement the logic of the custom rule, using standard user interface layouts and controls.

Migrating custom rule forms to harnesses and sections offers the following benefits:

  • User interfaces become HTML5 WC3 compatible and responsive to different screen sizes.
  • User interfaces become cross-browser compatible, rendered consistently in Google Chrome, Mozilla Firefox, Apple Safari, and recent versions of Microsoft Internet Explorer.
  • Rendering performance on modern browsers is dramatically improved.
  • User interface pop-up behavior is eliminated; all windows are rendered inside Designer Studio and end-user applications.

Pega 7 Express is available on-premises

Valid from Pega Version 7.1.9

You can now experience Pega 7 Express by switching your enterprise application from Designer Studio to express mode. By default, users with access to the Developer portal can switch between these two development environments. You can also create an express application to work in express mode exclusively.

Trial versions of Pega 7 Express continue to be available on the cloud. To view the documentation for both the cloud and on-premises environments, see Getting started with Pega 7 Express.

Access to Pega 7 Express from within Designer Studio is not supported on mobile devices.

Context-specific documentation is not available in express mode

Valid from Pega Version 7.1.9

Help topics that are opened from express mode display content that is specific to Designer Studio.

If your system is dedicated to applications that are developed in express mode exclusively, and you do not need Designer Studio help topics, you can set the Online Help URL field on the System Settings landing page to: https://pdn.pega.com/sites/default/files/help_p7e/procomhelpmain.htm. Alternatively, you can view the contextual help system for Pega 7 Express in a separate browser tab.

Design-time limitations in express mode

Valid from Pega Version 7.1.9

Some limitations apply when you develop an enterprise application in express mode. At design time, some features are disabled or have limited options when you configure them in Designer Studio and switch to express mode. The use of these features does not restrict the run-time behavior of your application; however, you cannot change the configuration of these features unless you switch from express mode to Designer Studio.

For more information about each limitation and the recommended action to take, see the following information:

Condition builder enhancements

Valid from Pega Version 8.5

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

Valid from Pega Version 8.5

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.

New JWT access token format: Authorized Access Token

Valid from Pega Version 8.5

Pega Platform™ is changing from using opaque tokens to using JSON Web (JWT) tokens and the JWT access token format: Authorized Access Token (AAT). An AAT enables a client application to validate the server for user permissions and authorizes a specific application to access specific parts of a user’s data.

The major benefits to using the JWT format are:

  • The JWT is a self-contained token that has authentication information, expire time information, and other user-defined claims digitally signed.
  • A single token can be used with multiple applications.
  • The tokens are short-lived and can minimize damage if transport security is compromised, as the token signature is verified.
  • As the token is verified with the signature, there is no need to verify against a database, thus reducing latency (usually important for Web APIs).

For more information, see Understanding authorized access tokens.

Improvements to OAuth 2.0 Services with Token Introspection Service and Token Denylist Service

Valid from Pega Version 8.5

Increase the security of user sessions by using the newly supported Token Introspection and Denylist services for OAuth 2.0.

Token Introspection service

Use the Token Introspection service to validate JSON Web Tokens (JWT). The Token Introspection service requires authentication. 

Pega now uses OAuth 2.0 access tokens called Authorized Access Tokens (AAT). 

Token Introspection service endpoint

The Token Introspection service endpoint provides the information about the status of access token and refresh token. Token introspection can be used to validate if a given token is still active or inactive. The token introspection endpoint determines whether the token is valid. The status indicates whether an access token or refresh token is valid or invalid: 

  • Valid tokens have the “active”:true status
  • Invalid tokens have the “active” :false status.

The inactive status can also be due to revocation. 

Token Denylist service

You can add tokens to the deny list in cases where suspicious activity might have occurred. The Token Denylist service provides a method for denying user access to the application by revoking the user's access token. This service can prevent a token from being used more than the specified number of times, which can be helpful in preventing replay attacks. Stolen tokens should be revoked using this service. A GET API is also available to get the list of denied tokens.

Keys endpoint

Pega Platform™ is changing from using opaque tokens to JSON Web (JWT) tokens. If this JWT is used by any other system, the public key is needed for signature verification. A new endpoint is exposed to provide these public keys in JWK format: https://host:port/prweb/api/oauth2/v1/token/keys.

 

For more information, see OAuth 2.0 Management Services.

Enhanced refresh token strategy

Valid from Pega Version 8.5

You now have more precise control over your refresh token expiration strategy. When a refresh token is enabled, you can choose to set its initial expiration based on the value provided by the IDP. The refresh token expiry can be derived from IDP’s session timeout when SSO is used with external IDP for user authentication in the authorization code grant flow. You can also specify a separate refresh token expiration strategy based on your use-case. 

These can be configured in the OAuth2 Client registration rule form.

For more information, see Enhanced refresh token strategy.

Enhancements to token lifetime limits

Valid from Pega Version 8.5

Pega Platform™ uses OAuth 2.0 authorization codes, access tokens, and refresh tokens to provide flexible token-based security for applications. Expiration settings for these codes and tokens now adhere to certain strict value range based on industry leading practices. For example, the lifetime specified for the authorization code must be in the range 1-600 seconds.

These can be configured in the OAuth2 Client registration rule form.

For more information, see OAuth 2.0 Management Services.

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