Published Release Notes

Post files and links with pxPostMessage API

The pxPostMessageAPI now supports text messages, file attachments, and hyperlinks. You can programmatically update Pulse streams using this API from activities or SLA rules.

Case Management

This release has continued to focus on improving the functionality of the design environment with improvements to the Case Designer and stage configuration. Additional end user capabilities were also added to allow for processing a wider variety of cases, for those with and without stages and improved bulk processing handling.

• Flow action processing now uses the primary page instead of the interest page when using case/stage local actions, so that embedded flows are properly populated.
• Case-wide local actions rely on pzInternalStageFlow when there are no active, non-hidden assignments on the case. These case-wide local actions will now appear on a stage-less flow with no assignments.
• If a (valid) error is displayed in the outline view, saving or clicking around will not delete the error - the error will remain as a reminder to the developer to solve whatever problem is being flagged.
• May now add Cascading Approval validation and edit the parameters from the Case Designer Stage and Step page.
• Page labelling ("Page 1 of X") appears in the history list presented in the audit tab.
• The bulk processing feature has been enhanced.
• The Outline View functionality was changed so that the visible page will no longer refresh each time a flow is edited.
• The Post value was added to the instructions text field, so data isn't lost between nodes in the outline View.
• When Assign to Operator or workbasket is included as a filter, the bulk processing gadget is supposed to get a list of assignments. The UI for the results was enhanced for assignments to include a column for instructions so that the different assignments on the same work item can be distinguished.
• When designing a case type’s stages, it is no longer possible to skip the last stage (by using the "skip stage when" setting). When creating or editing the last stage, developers may no longer set a skip when rule; if tried, the system will display a warning and prevent that. If a Skip When rule is set up for a stage, and then all the intervening stages are deleted so that this stage becomes the last stage, the warning will display, and the Skip When rule will not be visible. If another stage is then added after that, the Skip When rule becomes visible again.
• When one or more locked work objects are processed using the Process Selected Items button, the action will be performed on the selected work objects. If the action is successful, a green tick appears on the work object. If it is not successful, a red cross will appear.
• When the topmost RuleSet in the RuleSet Stack is locked, customers may now open up Outline View by clicking "Configure Process Details" and make exploratory changes to experiment. Because the RuleSet is locked, these changes may not be saved, but the experiment can be tried.

Quickly create ad-hoc cases

The My Cases work area on the Case Manager portal introduces a Quick Create feature that lets users create cases and assign tasks that are not included in the processing of business cases (instances of case types defined in the Cases Explorer).  For example, a manager can create a case and a task to set up a phone conference with her staff, or a reminder to enroll in an online seminar. Users can also set up a series of tasks to represent all they work they need to do to accomplish a specific goal.

Enhanced Wait shape

Pega Platform™ now supports the enhanced Wait shape that configures the case to wait for the resolution of all child cases instead of only the child cases of a specific type. When you set up the Wait shape to stop a case until it reaches a certain status, you can decide whether the shape considers statuses from a whole case life cycle, or only the statuses after the wait begins. The enhanced Wait shape provides you with greater control over resolution of your cases. 

For more information, see Pausing and resuming processes in cases in Dev Studio, Pausing and resuming processes in cases in App Studio.

Case tags for improved case search

Pega Platform™ now supports enhanced tagging for case types so that you can search cases by tags. As a result, tagging is more consistent because you can define a set of suggested tags that users can add to their posts and cases. When users search for cases, they can apply several filters, for example, recently added or most frequently used tags.

For more information about tags, see Tagging cases in Dev Studio, Tagging cases in App Studio.

Case notification enhancements

Pega Platform™ now supports creating case notifications directly in Case Designer in App Studio and Dev Studio, so that you do not need to create a notification rule first and then provide the rule name in a case. You can speed up and simplify case creation by specifying recipients for each notification, without the need to create a data page for the recipients. Push notifications and email subjects can now also include properties, for example, a case ID or a goal and deadline.

For more information, see Sending event notifications from cases in Dev Studio, Sending event notifications from cases in App Studio.

Improved and simplified field-level auditing

To track the progress of your work and maintain the compliance of your cases, both App Studio and Dev Studio now support field-level auditing for case fields. Your application tracks and displays information about user updates to scalar fields, field groups, and field group lists, at any level of your case data model. For example, you can check previous and current field values, the last user to change the values, and the time of their modification. 

For more information, see Track changes in cases with improved field-level auditing (8.4), Enabling field-level auditing in Dev Studio, Enabling field-level auditing in App Studio.   

Creation of case documents in a case life cycle

To save time and further automate your business processes, Pega Platform™ now supports generating case documents as part of the case life cycle. You can ensure that the documents include all necessary information by first creating a document template in a word processor. When you create a template, you add dynamic tags that your application populates with relevant data unique to each case, for example, the case ID and current date. To make your documentation more meaningful, you can also include attachments.

For more information, see Generate case documents in a case life cycle (8.4), Generating case documents in Dev Studio, Generating case documents in App Studio.

Pulse configurations in the case type settings

In both App Studio and Dev Studio you can now configure Pulse in a simplified and user-friendly way, in the case type settings. Add Pulse posts to cases, define default and add new feed sources, and then customize the Pulse label, all without performing advanced actions, such as configuring sections. You can also define visibility conditions for each post type.

For more information, see Start collaborating faster with simplified Pulse configuration (8.4), Configuring Pulse for case types in Dev Studio, Configuring Pulse for case types in App Studio.

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.