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.

INC-161463 · Issue 638000

Case Dependency corrected for different access groups

Resolved in Pega Version 8.3.6

Creating a queue item as part of the case dependency was not working as expected when the access groups of the dependent cases were different. Investigation showed that in this scenario, the logic was looping differently and the DependencyList page in pxCheckFlowDependencies was getting removed. To resolve this, the DependencyList page has been moved so it is processed inside the DependencyList.pxResults loop.

INC-163154 · Issue 638097

Code updated for bulk actions buttons

Resolved in Pega Version 8.3.6

After upgrade, hovering over the "Filter case" button in pzBullkUpdate and the "Create" and "Clear" buttons in pzBulkAddActions caused them to disappear. The warning "This button generates markup that was used to support the older browsers. It is recommended that you update it to the newer markup" was shown, and an update code button appeared. Some custom rules exhibited the same behavior initially, but worked as expected after updating the code and saving them. This has been resolved by updating the buttons in pzBulkUpdate and pzAddBulkActions with the latest UI technologies used for button control codes.

INC-164413 · Issue 636125

Updated timestamp handling for duplicate key issue with PyCompleteAutomation

Resolved in Pega Version 8.3.6

Occasionally a robot failed to complete a case due to a duplicate key exception. This was an issue with the History record creation due to duplicate key erlated to the timestamp, and has been resolved by updating the timestamp handling so that the REST API will use 'getCurrentTimeStampUnique' and for other cases 'pxGetCurrentTimeStampThreadUnique' will be used.

INC-172485 · Issue 649053

Check added for WorkParty property to catch changes

Resolved in Pega Version 8.3.6

After configuring a send email shape to send email to work parties, proceeding through the flow without work parties and then triggering the send email shape and creating the Fix correspondence assignment worked as expected. If the work party details were later updated and the send email shape was triggered again for the Fix correspondence assignment, the error message "No role defined to work object" appeared. This was an issue with the handling of the email flow the second time through: PyCorrPage.pyCorrPartyRole did not have the work object party details which were added to the work object after the fix correspondence assignment was created, and SendSimpleEmail was not designed to handle the email that needs to be retried during the FixCorrespondence flow call. To resolve this, the system will check whether the pyWorkParty property exists prior to calling the PartyCorrPreferences HTML rule.

INC-142831 · Issue 605475

Corrected Outlook web inline image handling

Resolved in Pega Version 8.3.6

Outlook web was not able to render inline images and instead added them as external attachments. Investigation showed inline images were not being rendered properly in Outlook web due to the disposition not being set. This has been corrected.

INC-143668 · Issue 617486

Performance improvements for Attachment Migration Utility

Resolved in Pega Version 8.3.6

The Attachment Migration Utility was showing a zero count for attachments in the Pega Database. This was traced to the underlying report definition that retrieves data for the Attachment Migration Utility timing out, and has been resolved by updating the activities to improve performance for applications having a large number of attachments without customization.

INC-143908 · Issue 606548

Data Page Save correct in batch mode

Resolved in Pega Version 8.3.6

After configuring a List type savable Data Page with save activity in Code-Pega-List, the save data page was triggered from utility of flow from the queue processor to handle queueing 10k data items and creating 10k work objects. When this was run, a field dpClassName was being changed by different threads in This has been resolved by making the class stateless to ensure thread safety.

INC-144387 · Issue 605341

Support added for allow list for LaxRedirectStrategy

Resolved in Pega Version 8.3.6

When using Connect REST with POST to access a third-party service deployed on multiple nodes, the load balancer sometimes replied 302 with Location header. The ability to allow the REST connector to automatically follow these redirects even in the case of POST messages is supported by Apache http client via LaxRedirectStrategy, but REST Connectors need both rule and engine enhancements to allow for this. To support this use, an allow list has been implemted for hostnames. This will allow the connector to be configured to follow the LaxRedirectStrategy only when the hostname of the redirect location is in the allow list. The default will continue to block the redirect.

INC-144913 · Issue 607993

Handling added for unknown ProducerID exception

Resolved in Pega Version 8.3.6

An "UnknownProducerIdException" was seen in the PegaRULES and Kafka broker logs for Stream services. This exception is raised by the broker if it can not locate the producer metadata associated with the producerId in question. This could happen if, for example, the producer's records were deleted because their retention time had elapsed. Once the last records of the producerId are removed, the producer's metadata is removed from the broker and future attempts to append additional metadata will return this exception. To resolve this, a new producer will be used if the old one is unknown.

INC-145756 · Issue 619292

Logging for MultiNodeSynchronize lock attempts changed from error to warn

Resolved in Pega Version 8.3.6

The File Listener was logging numerous errors stating "Unable to establish MultiNodeSynchronize lock while trying to determine if listener is enabled for this node". Handling has been previously established for error cases when the Listener is unable to establish a MultiNodeSynchronize lock, but this condition continued to be logged as an error even though it was not related to any failures in functionality. To resolve the logging issue, the logger level has been changed from ERROR to WARN.

We'd prefer it if you saw us at our best. is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us