Genesys Cloud - Main

Hello @Gina Foran

I don't know if I properly understood the scenario, but could you confirm how the survey is being launched today?

If Set Post-Flow is configured before the caller chooses between waiting for an agent and requesting a callback, both paths may inherit the same survey behavior. In that case, I would either set the post-flow only on the normal voice path, or explicitly clear or avoid it on the callback path.

Another option is to pass your own control value. For example, before the post-flow is reached, set something like

SurveyEligible = true for normal inbound voice calls and

SurveyEligible = false or CallType = Callback before creating the callback.

That said, if you can control the path inside Architect, I would prefer setting your own flag before the callback is created. It is usually cleaner than trying to infer later whether the interaction came from the callback path.

Hi Arthur,

Yes the set post-flow is configured before the caller chooses between waiting for an agent and requesting a callback but I was able to add a clear post-flow on the callback route so it doesn't play the survey incorrectly. The issue is that I added audio before the set post flow and Im not sure how to get rid of that on the callback flows. The callbacks are only offered after a certain amount of time so some of the calls don't go through the callback flow portion in order to place the audio after the callback selection.

Thank you

Hello @Gina Foran

I don't know if I properly understood the scenario, but could you confirm how the survey is being launched today?

If Set Post-Flow is configured before the caller chooses between waiting for an agent and requesting a callback, both paths may inherit the same survey behavior. In that case, I would either set the post-flow only on the normal voice path, or explicitly clear or avoid it on the callback path.

Another option is to pass your own control value. For example, before the post-flow is reached, set something like

SurveyEligible = true for normal inbound voice calls and

SurveyEligible = false or CallType = Callback before creating the callback.

That said, if you can control the path inside Architect, I would prefer setting your own flag before the callback is created. It is usually cleaner than trying to infer later whether the interaction came from the callback path.

Hi,

In this case, I would try using Clear Post-Flow in the callback flow, but it will depend on how your callback flow is built.

If the caller passes through an Architect branch before the callback is created, you can add the Clear Post-Flow action there. That should remove the survey post-flow from the interaction before the callback path continues.

If the flow design does not make it easy to use the native Clear Post-Flow action at the right point, another option could be a Genesys Cloud Data Action from Architect to remove the post-flow action through the API:

DELETE /api/v2/conversations/calls/{conversationId}/participants/{participantId}/communications/{communicationId}/postflowaction

But I would only go this route if the native Architect action does not fit the flow design, because the API approach depends on identifying the correct participant and communication IDs.

So, I would first review exactly where the callback is created and test Clear Post-Flow immediately before that step.

Hi Arthur,

Yes the set post-flow is configured before the caller chooses between waiting for an agent and requesting a callback but I was able to add a clear post-flow on the callback route so it doesn't play the survey incorrectly. The issue is that I added audio before the set post flow and Im not sure how to get rid of that on the callback flows. The callbacks are only offered after a certain amount of time so some of the calls don't go through the callback flow portion in order to place the audio after the callback selection.

Thank you

Hello @Gina Foran

I don't know if I properly understood the scenario, but could you confirm how the survey is being launched today?

If Set Post-Flow is configured before the caller chooses between waiting for an agent and requesting a callback, both paths may inherit the same survey behavior. In that case, I would either set the post-flow only on the normal voice path, or explicitly clear or avoid it on the callback path.

Another option is to pass your own control value. For example, before the post-flow is reached, set something like

SurveyEligible = true for normal inbound voice calls and

SurveyEligible = false or CallType = Callback before creating the callback.

That said, if you can control the path inside Architect, I would prefer setting your own flag before the callback is created. It is usually cleaner than trying to infer later whether the interaction came from the callback path.

Hi Arthur,

I did already add a clear post flow and that worked to remove the survey from playing during the callback calls but the issue is the audio. I have audio that plays to announce the survey will continue after the call and to please stay on the line. We would like it to play before it connects to the agent but only for noncallback calls.

Thank you!

Hi,

In this case, I would try using Clear Post-Flow in the callback flow, but it will depend on how your callback flow is built.

If the caller passes through an Architect branch before the callback is created, you can add the Clear Post-Flow action there. That should remove the survey post-flow from the interaction before the callback path continues.

If the flow design does not make it easy to use the native Clear Post-Flow action at the right point, another option could be a Genesys Cloud Data Action from Architect to remove the post-flow action through the API:

DELETE /api/v2/conversations/calls/{conversationId}/participants/{participantId}/communications/{communicationId}/postflowaction

But I would only go this route if the native Architect action does not fit the flow design, because the API approach depends on identifying the correct participant and communication IDs.

So, I would first review exactly where the callback is created and test Clear Post-Flow immediately before that step.

Hi Arthur,

Yes the set post-flow is configured before the caller chooses between waiting for an agent and requesting a callback but I was able to add a clear post-flow on the callback route so it doesn't play the survey incorrectly. The issue is that I added audio before the set post flow and Im not sure how to get rid of that on the callback flows. The callbacks are only offered after a certain amount of time so some of the calls don't go through the callback flow portion in order to place the audio after the callback selection.

Thank you

Hello @Gina Foran

I don't know if I properly understood the scenario, but could you confirm how the survey is being launched today?

If Set Post-Flow is configured before the caller chooses between waiting for an agent and requesting a callback, both paths may inherit the same survey behavior. In that case, I would either set the post-flow only on the normal voice path, or explicitly clear or avoid it on the callback path.

Another option is to pass your own control value. For example, before the post-flow is reached, set something like

SurveyEligible = true for normal inbound voice calls and

SurveyEligible = false or CallType = Callback before creating the callback.

That said, if you can control the path inside Architect, I would prefer setting your own flag before the callback is created. It is usually cleaner than trying to infer later whether the interaction came from the callback path.

Hi, Gina!

In this scenario, I think breaking the audio is an important part of the solution.

If the current audio has both the general queue message and the survey announcement in the same prompt, callback callers will still hear the survey part before you have a chance to exclude them. 

I would test splitting the audio into separate parts. For example, keep the general queue message as one prompt, and separate the "please stay on the line for the survey" message into another prompt or audio sequence.

Then, you could use a control flag to decide whether to play the survey announcement part. When the caller reaches the callback flow, set something like CallbackFlow = true. In the in-queue flow, use Get Participant Data before the audio sequence.

If CallbackFlow = true, play only the normal queue audio and skip the survey announcement.

If CallbackFlow is empty or false, play the normal queue audio plus the survey announcement.

This way, you are not trying to undo audio that already played. You are separating the survey-related message and only adding it when the caller is confirmed as a non-callback call. 

Hi Arthur,

I did already add a clear post flow and that worked to remove the survey from playing during the callback calls but the issue is the audio. I have audio that plays to announce the survey will continue after the call and to please stay on the line. We would like it to play before it connects to the agent but only for noncallback calls.

Thank you!

Hi,

In this case, I would try using Clear Post-Flow in the callback flow, but it will depend on how your callback flow is built.

If the caller passes through an Architect branch before the callback is created, you can add the Clear Post-Flow action there. That should remove the survey post-flow from the interaction before the callback path continues.

If the flow design does not make it easy to use the native Clear Post-Flow action at the right point, another option could be a Genesys Cloud Data Action from Architect to remove the post-flow action through the API:

DELETE /api/v2/conversations/calls/{conversationId}/participants/{participantId}/communications/{communicationId}/postflowaction

But I would only go this route if the native Architect action does not fit the flow design, because the API approach depends on identifying the correct participant and communication IDs.

So, I would first review exactly where the callback is created and test Clear Post-Flow immediately before that step.

Hi Arthur,

Yes the set post-flow is configured before the caller chooses between waiting for an agent and requesting a callback but I was able to add a clear post-flow on the callback route so it doesn't play the survey incorrectly. The issue is that I added audio before the set post flow and Im not sure how to get rid of that on the callback flows. The callbacks are only offered after a certain amount of time so some of the calls don't go through the callback flow portion in order to place the audio after the callback selection.

Thank you

Hello @Gina Foran

I don't know if I properly understood the scenario, but could you confirm how the survey is being launched today?

If Set Post-Flow is configured before the caller chooses between waiting for an agent and requesting a callback, both paths may inherit the same survey behavior. In that case, I would either set the post-flow only on the normal voice path, or explicitly clear or avoid it on the callback path.

Another option is to pass your own control value. For example, before the post-flow is reached, set something like

SurveyEligible = true for normal inbound voice calls and

SurveyEligible = false or CallType = Callback before creating the callback.

That said, if you can control the path inside Architect, I would prefer setting your own flag before the callback is created. It is usually cleaner than trying to infer later whether the interaction came from the callback path.

Hi Arthur,

It is separated but the problem is the callback is only offered after x amount of time so some calls don't even reach that part of the callback flow so I would have no place to put the audio that would be at a spot where it would be able to play for the noncallback calls but then not for the callback calls.

Hi, Gina!

In this scenario, I think breaking the audio is an important part of the solution.

If the current audio has both the general queue message and the survey announcement in the same prompt, callback callers will still hear the survey part before you have a chance to exclude them. 

I would test splitting the audio into separate parts. For example, keep the general queue message as one prompt, and separate the "please stay on the line for the survey" message into another prompt or audio sequence.

Then, you could use a control flag to decide whether to play the survey announcement part. When the caller reaches the callback flow, set something like CallbackFlow = true. In the in-queue flow, use Get Participant Data before the audio sequence.

If CallbackFlow = true, play only the normal queue audio and skip the survey announcement.

If CallbackFlow is empty or false, play the normal queue audio plus the survey announcement.

This way, you are not trying to undo audio that already played. You are separating the survey-related message and only adding it when the caller is confirmed as a non-callback call. 

Hi Arthur,

I did already add a clear post flow and that worked to remove the survey from playing during the callback calls but the issue is the audio. I have audio that plays to announce the survey will continue after the call and to please stay on the line. We would like it to play before it connects to the agent but only for noncallback calls.

Thank you!

Hi,

In this case, I would try using Clear Post-Flow in the callback flow, but it will depend on how your callback flow is built.

If the caller passes through an Architect branch before the callback is created, you can add the Clear Post-Flow action there. That should remove the survey post-flow from the interaction before the callback path continues.

If the flow design does not make it easy to use the native Clear Post-Flow action at the right point, another option could be a Genesys Cloud Data Action from Architect to remove the post-flow action through the API:

DELETE /api/v2/conversations/calls/{conversationId}/participants/{participantId}/communications/{communicationId}/postflowaction

But I would only go this route if the native Architect action does not fit the flow design, because the API approach depends on identifying the correct participant and communication IDs.

So, I would first review exactly where the callback is created and test Clear Post-Flow immediately before that step.

Hi Arthur,

Yes the set post-flow is configured before the caller chooses between waiting for an agent and requesting a callback but I was able to add a clear post-flow on the callback route so it doesn't play the survey incorrectly. The issue is that I added audio before the set post flow and Im not sure how to get rid of that on the callback flows. The callbacks are only offered after a certain amount of time so some of the calls don't go through the callback flow portion in order to place the audio after the callback selection.

Thank you

Hello @Gina Foran

I don't know if I properly understood the scenario, but could you confirm how the survey is being launched today?

If Set Post-Flow is configured before the caller chooses between waiting for an agent and requesting a callback, both paths may inherit the same survey behavior. In that case, I would either set the post-flow only on the normal voice path, or explicitly clear or avoid it on the callback path.

Another option is to pass your own control value. For example, before the post-flow is reached, set something like

SurveyEligible = true for normal inbound voice calls and

SurveyEligible = false or CallType = Callback before creating the callback.

That said, if you can control the path inside Architect, I would prefer setting your own flag before the callback is created. It is usually cleaner than trying to infer later whether the interaction came from the callback path.