Skip to main content

Resolved Issues

View the resolved issues for a specific Platform release.

Go to download resolved issues by patch release.

Browse release notes for a selected Pega Version.

NOTE: Enter just the Case ID number (SR or INC) in order to find the associated Support Request.

Please note: beginning with the Pega Platform 8.7.4 Patch, the Resolved Issues have moved to the Support Center.

SR-D15262 · Issue 486888

GetNextWork properly switches applications for 'most urgent'

Resolved in Pega Version 8.3

Post upgrade, the "Get most urgent" button was unable to open a service request from another application to which the operator had access. In this case, the Operator had access to the Canada and USA applications by default, but when a service request from the Canada application context was available in the list, the Get most urgent functionality failed to switch the application context from USA to Canada in order to open the work item. Investigation showed that the GetNextWork activity was being overridden in the Pega-DecisionManager ruleset in rule resolution and that the the Pega-ProcessEngine and Pega-DecisionManager had different versions of the activity. This has been resolved by upgrading GetNextWork in the Pega-DecisionManager ruleset.

SR-B8133 · Issue 277199

Support added for cloning SLA agents

Resolved in Pega Version 7.3

The SLA worker agent was not working as expected based on a prior recommendation to clone agents. The cloned agents are not handling any requests. The original agent is still working, but all 3 clones do not perform any work. 6 nodes, for agents per node, and on each node only the original node is working. Cloned agents were not processing work in production if they were duplicated from SLA agents. In order to support this use, a new feature has been added to agent to allow dequeueing pages queued for another agent. This new configuration setting clones Pega-ProCom to multiple custom rulesets or creates a new agent rule in a custom ruleset with multiple rows for the ServiceLevelEvents agent in that rule. Example:

SR-B35117 · Issue 292760

Split-for shape "open flow" works as expected

Resolved in Pega Version 7.3

When working with a flow that contains a Split-for each shape which loops pyWorkParty and executes a flow on Data-Party class, an error was generated if there was a right-click on the sub-flow shape and "Open flow" was chosen. The sub-flow opened properly if there was a right-click on the sub-flow shape, "View Properties" was chosen, then a click on the "Open" icon right of the flow name. This was traced to the Top Class being passed for opening the flow rule in the Navigation rule "pyMenu" of "Data-MO-Activity-SubProcess-SplitForEach" class. To fix this, the class has been changed from Top to ".pyPageClass" in the Navigation rule "pyMenu" of "Data-MO-Activity-SubProcess-SplitForEach" to open the flow rule

SR-D3371 · Issue 439505

Association Resolver updated to handle filters created on secured properties

Resolved in Pega Version 8.3

After creating a Report Definition in a class (Example Class A) that had an Association in that report with Class B, no results were generated from the report when an Access Control Policy and Access Control Policy Condition were created for Class A and Class B where the Class B had an ACPC with a Value field that referred to a Data Page or clipboard page property. Investigation showed the system was not able to resolve the actual value of the datapage property in the generated SQL query due to Association Resolver resetting the filter value (the Page reference in this case) of a filter that is created on a secured property. This has been corrected by updating Association Resolver to not reset the right operand for a filter that is created on a secured property.

SR-D13388 · Issue 485167

Handling added for minor case creation errors

Resolved in Pega Version 8.3

When creating a case, if any step status failed due to a non-critical reason which did not impact case creation (for example, a mandatory parameter was missing from the data page), that failure state was propagated to SaveNew and ultimately to the case creation API. As a result of this failure report, no case ID information would be reported back to the requestor even though the case was created, and the API responded with status 500 - internal service error. This has been resolved by removing the StepStatusFail check from pzCreateCaseInternal so that non-breaking errors will not result in a 500 error, and a check has been added for page messages in svcAddWorkObject and svcPerformFlowAction so that validation messages are returned.

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