Genesys Cloud - Developer Community!

Hi Marc,

Apologies, I just checked and realised that refers to the same thread you already posted.

My understanding is that there isn't currently a direct Flush Audio equivalent supported within Bot Flows. Hopefully someone who has implemented a similar asynchronous polling pattern differently can share their approach or any alternative workarounds they've found.

Thanks a lot Phaneendra;

Tested the Set Screen Pop : doesn't work.

I need to fing something else like a dummy ask for ?

Regards

Marc

Hi Marc,

Apologies, I just checked and realised that refers to the same thread you already posted.

My understanding is that there isn't currently a direct Flush Audio equivalent supported within Bot Flows. Hopefully someone who has implemented a similar asynchronous polling pattern differently can share their approach or any alternative workarounds they've found.

Thanks for testing Marc.

I was wondering whether a short Wait action inside the loop might help. If the participant data is being updated asynchronously by the Workflow, introducing a small delay between checks may give the update time to complete and prevent the loop from racing ahead.

Not sure if you've already tried that approach, but it might be worth testing.

Thanks a lot Phaneendra;

Tested the Set Screen Pop : doesn't work.

I need to fing something else like a dummy ask for ?

Regards

Marc

Hi Marc,

Apologies, I just checked and realised that refers to the same thread you already posted.

My understanding is that there isn't currently a direct Flush Audio equivalent supported within Bot Flows. Hopefully someone who has implemented a similar asynchronous polling pattern differently can share their approach or any alternative workarounds they've found.

Thanks Phaneendra

The Wait action is not available in an Architect Bot Flow.

I need an action available for bot flows and  genereting a kind of flush audio. 

May be a Set Language will. I will try in the looping task of my flow and in another task calling it from my loop (Set Language apply only when changing task in a flow).

I let you know the results.

Regards

Marc

Thanks for testing Marc.

I was wondering whether a short Wait action inside the loop might help. If the participant data is being updated asynchronously by the Workflow, introducing a small delay between checks may give the update time to complete and prevent the loop from racing ahead.

Not sure if you've already tried that approach, but it might be worth testing.

Thanks a lot Phaneendra;

Tested the Set Screen Pop : doesn't work.

I need to fing something else like a dummy ask for ?

Regards

Marc

Hi Marc,

Apologies, I just checked and realised that refers to the same thread you already posted.

My understanding is that there isn't currently a direct Flush Audio equivalent supported within Bot Flows. Hopefully someone who has implemented a similar asynchronous polling pattern differently can share their approach or any alternative workarounds they've found.

If you are passing data from an inbound call flow into a bot flow, the recommended approach is to use bot input variables rather than relying on participant data.

Participant data updates can have a delay, and the bot flow may attempt to read the values before they are available, even if they were set correctly in the inbound flow before transferring to the bot.

If you still want to use a retry/loop approach, you can use a Communicate block with blank audio (for example, 5 seconds) between attempts. Keep the retries limited (maximum 3 loops) to avoid creating an unintended infinite execution path.

Thanks for your answer Harisankar

I'm not passing data from a Inbound call flow to a Bot flow but from a Workflow to a Bot flow. The only way I know in Architect to get data from a Workflow is to use participant data.

And in my case the data action request takes between 3 and 10 seconds to answer, in more than 99% of the cases Participant Data are set quicker than this.

Regards

Marc

Marc

If you are passing data from an inbound call flow into a bot flow, the recommended approach is to use bot input variables rather than relying on participant data.

Participant data updates can have a delay, and the bot flow may attempt to read the values before they are available, even if they were set correctly in the inbound flow before transferring to the bot.

If you still want to use a retry/loop approach, you can use a Communicate block with blank audio (for example, 5 seconds) between attempts. Keep the retries limited (maximum 3 loops) to avoid creating an unintended infinite execution path.