The actions of a common module is embedded into the calling flow when it's published, it does not run as a separate flow at runtime. It will never get you around any limit. https://help.mypurecloud.com/articles/work-with-common-module-flows/
What does flush audio do then if not remove the "cached audio"?
You're talking about a different meaning of "audio" and a different type of cache. The cached audio in this case is not specifically a prompt. All audio to be played to the customer (TTS and prompts) is buffered (cached) and flushed (played out loud) periodically. Instead of playing the 1st piece of audio, do some other actions that take some milliseconds, play the 2nd piece,... what happens is queue the 1st piece of audio, do other actions, queue 2nd piece of audio, . . . . play all queued audio at once.
https://help.mypurecloud.com/articles/audio-buffer-and-flush-in-architect-flows/
https://help.mypurecloud.com/articles/flush-audio-action/
https://help.mypurecloud.com/faqs/when-does-architect-force-audio-to-flush/
Would that process work?
In theory but test it out first and make sure you're happy with the results. I image it could screw with your reporting & analytics; the estimated wait times for the queue will probably be somewhat inaccurate. You're going to have to use participant data to keep track of the loop increment. Make sure you really want to add a full minute of priority every time it loops.
Honestly the data table is a better idea. You can even use it to hold the name of the prompt to play. When you want a different audio recording, create a new prompt, upload the recording, then update the data table row with the new prompt name.
Original Message:
Sent: 02-20-2024 19:24
From: Jim Mayer
Subject: In Queue Audio Prompt Real Time Update
To make sure I am following, FindUserPrompt and ToAudio(FindUserPrompt()) these actions themselves do not cache the prompts, however they cache the prompt for each flow instance when it starts so even if the prompt changes, its running off of the "cached" prompt, right?. So in the case of transfering to get around the "caching", it would have to a flow rather than a common module?
What does flush audio do then if not remove the "cached audio"?
Lets say we wanted to go the route of transfering between flows, one way around that would be setting call priority based on how many times its gone through the "loop" so to speak of transferring back and forth between flows, right? So if its their very first time into the IQF, we would set a variable to 0, and set call priority to that variable. If it wasnt their first time back in the flow, we check the variable, increment it by 1, and then set call priority to that. Would that process work?
------------------------------
Jim Mayer
Colorado Springs Utilities
Original Message:
Sent: 02-20-2024 17:58
From: Melissa Bailey
Subject: In Queue Audio Prompt Real Time Update
The find functions & actions cache the objects they look up for the duration of the flow instance. Some examples:
1) Call comes into flow1. Look up prompt X--1st lookup of this prompt in this flow instance, fetch it. Do some other stuff. Look up prompt X--hang up, we've already done that, just use what we already retrieved.
2) Call comes into flow1. Look up prompt X--1st lookup of this prompt in this flow instance, fetch it. Transfer to flow2. Look up prompt X--new instance of this other flow, fetch it.
3) Call comes into flow1. Look up prompt X--1st lookup of this prompt in this flow instance, fetch it. Transfer to flow2. Transfer back into flow1. Look up prompt X--new instance of flow1, so fetch it.
For an inqueue flow, you don't want to transfer away & back in b/c that will move the caller to the end of the queue. Are you okay with playing TTS to the customer instead of a prompt recording? If so, use a data table with the string of the TTS to play and look that up instead. The flow will get the updated value for that.
------------------------------
Melissa Bailey
Genesys - Employees
Original Message:
Sent: 02-20-2024 17:39
From: Jim Mayer
Subject: In Queue Audio Prompt Real Time Update
Hi Paul, thank you for your reply!
I have tried the ToAudio(FindUserPrompt("The_Prompt")) as well as FindUserPrompt action but these are not working in either the IQF, it will play the prompt to new callers who come into the call flow, but not callers who are already in the IQF. From what I have been reading it shouldn't cache the content of the prompt when using either of these options and should play the most current message.
------------------------------
Jim Mayer
Colorado Springs Utilities
Original Message:
Sent: 02-20-2024 17:06
From: Paul Simpson
Subject: In Queue Audio Prompt Real Time Update
The problem you have, I believe, is for new Prompts (or edited Common Modules) to be picked up, the consuming flow (in this case the in-queue flow) must be re-published. When this happens, calls already in the flow continue in the original version of the flow.
One way to do this might be to dereference the Prompt name. So, rather than specifying the Prompt directly in your Play Audio, use "Expression" and then put something like:
ToAudio(FindUserPrompt("The_Prompt"))
as the expression. With any luck, this will cause the system to load the new version immediately.
HTH
------------------------------
Paul Simpson
Views expressed are my own and do not necessarily reflect those of my employer.
Original Message:
Sent: 02-20-2024 15:45
From: Jim Mayer
Subject: In Queue Audio Prompt Real Time Update
Hi all,
Looking for some advice / insight / help on a problem I am running into with an in queue flow and playing a real time updated prompt to users who are already in the queue.
Situation is when we have an outage with our services, we are looking for a way to let customers who are already in an in queue flow to hear the message about the outage to help deflect some of the volume we receive during these times. In reviewing the resource center and this thread, it appears as if a dynamically referenced audio prompt should play a real time message (IE replacing blank audio in a prompt with new content, customers should hear that new content who are already in an IQF). What we are running into when testing this is once the audio prompt is updated to anything other than the blank audio, the blank audio is still playing in the prompt rather than the new content. I have tried doing as a call to a common module to play the audio and then sending back to IQF, find user prompt action into play audio and referencing the variable as the prompt name to play, wrapping the play audio in flush audio, using ToAudio(FindUserPrompt()) expression, but it will not play anything other than the blank audio until I end the call and call back and only then do I hear the new content.
Any idea or insights on what I may be doing wrong or another solution to this situation would be appreciated.
#ArchitectureandDesign
------------------------------
Jim Mayer
Colorado Springs Utilities
------------------------------