Set Participant Data Lost in Post-Call Survey Flow

Hello everyone. I oversee the quality management process for a team of two hundred agents. We recently implemented post-call survey flows in Architect to gather customer feedback. My goal is to attach the survey score directly to the interaction so my supervisors can view it during their quality evaluations. However, I am encountering an issue where the custom participant data I set in the survey flow using the Set Participant Data action is not visible in the Interaction Details view or the Quality Management evaluation screen. I have verified that the variable is assigned correctly within the flow before the disconnect block. Why is this data being lost after the survey completes, and how can I ensure it remains attached to the agent interaction?

Greetings Ami. I completely understand the challenge you are facing, as we recently rolled out a similar initiative for our own contact center teams. The issue stems from how Genesys Cloud handles the post-call survey leg of the interaction.

When the call transfers to the survey flow, it technically creates a new segment or even a new conversation leg, depending on your transfer method. If you are using a blind transfer to the survey flow, the original agent conversation leg is already disconnected.

Therefore, setting participant data at that point only attaches it to the survey leg, not the agent leg. To resolve this, you must use the Transfer to In-Queue Flow or a secure pause mechanism if you want the data tied to the original conversation ID that the quality evaluators are reviewing.

That is correct. Our operations team encountered this exact barrier last quarter. If you execute a blind transfer to the survey IVR, the agent is already disconnected.

The platform considers the agent interaction finished. Any participant data you set in the survey flow stays isolated with the survey.

If you want the survey score on the agent interaction record, you must configure a custom Data Action. Have the survey flow trigger the Data Action, pass the original conversation ID, and use the platform API to patch the participant attributes on the original agent leg.

It is a complex workaround, but it functions reliably.

This is a classic architectural oversight that I have to explain in every single training class. It is incredibly frustrating that the platform does not natively link survey flow variables back to the primary agent evaluation screen without custom API integrations. the previous poster is entirely correct.

You cannot rely on the native Set Participant Data block in a disconnected survey leg. You must build a custom Data Action that targets /api/v2/conversations/{conversationId}/participants/{participantId}/attributes.

It requires you to capture the original agent participant ID before the transfer and pass it into the survey flow as a flow variable. It is completely unintuitive for standard administrators.