Transfer assignment when case is in screenflow

User Experience
,
1

Hi,

There is a requirement to implement a screen flow with three screens and enable transfer of assignments when there is a need to move the case to another queue or user. However, we have observed a limitation: the case cannot be transferred while it is in a screen flow, as routing is only supported at the start of the flow.

It would be greatly appreciated if you could suggest a workaround to support assignment transfers in this scenario.

2

Screenflow designed so the flow can be completed by same user, you can’t send the case to another user or WB while working with screen flow. You need to look your design again if you need to transfer the case.

3

While screen flows are structurally designed to be executed end-to-end by a single user, you can technically force a transfer in exceptional scenarios (such as an operator suddenly becoming unavailable).

To do this, you need to update the routing references in both the assignment instance and the active flow metadata:

  1. Update the Assign-Worklist instance to point to the new operator.

  2. Update the corresponding pxFlow(FlowName) page on the case, specifically setting the new operator ID in:

    • .pyFlowParameters.AssignTo

    • .pyFlowParameters.DefaultAssignTo

Once these references are updated, the screen flow will successfully resume from that specific step for the new user. However, this should strictly be used as an administrative workaround rather than a core application design pattern.

4

As @MISHR said, screenflow assignments must be worked by the same user. If you’re expecting different users in the screenflow, then you may need to change the design. For exception scenarios, use TransferAssignment to route the users from one user to another user.

5

Thanks to everyone for the replies. Since the requirement is to support both back-and-forth navigation and assignment transfers while within a screen flow, we have decided to proceed with a standard flow and enable back navigation.

6

Good choice :slight_smile: That is what I would have recommended.

For anyone that hits this issue in the future, some good reads:

And we have feedback on our backlog for this (EPIC-93411)

7

Great insight, and thanks for sharing this solution. I particularly appreciate the detailed explanation around updating both the Assign-Worklist instance and the pxFlow(FlowName) page (AssignTo and DefaultAssignTo) to allow a screen flow to continue with a different operator.

I have a related question that extends this scenario.

Suppose the assignment has an SLA configured, and the Goal event is set up to send a notification to the assigned operator. If the assignment is transferred to another operator before the SLA Goal is reached, and the assignment routing information is manually updated as described above, how does the underlying SLA processing behave?

Specifically:

  • Will the existing SLA automatically recognize the new assignee and send the Goal notification to that operator?
  • Or does the SLA continue to work with the context that existed when it was originally created?
  • Do we need to implement custom logic to determine the current assigned operator at the time the Goal event executes?
  • Is there any OOTB Pega mechanism that automatically resolves the notification recipient based on the current assignment owner after a reassignment?

I’m interested in understanding the recommended and supportable approach for ensuring SLA notifications are always sent to the current assignee following an assignment transfer. Any insights or best practices would be greatly appreciated. Thanks!