Initially I did like this but the thing is that when you use the Play Audio action, the prompt playing is triggered (the audio is put in a playing queue) and the flow will continue. meaning that if you collect the current time before and after playing the prompt, you will realize that the time difference is a few milliseconds even if your prompt is 10 seconds. As a workaround I found the Flush Audio function which will wait until the prompt is being played.
Original Message:
Sent: 09-03-2025 19:06
From: Nick Tait
Subject: Time Based Events in Architect
As an idea, maybe you could get the current timestamp at the start of the in-queue flow, then calculate the timestamp (in the future) that you want the 'event' to occur, then each time you play a treatment (i.e. announcement or music) specify a timeout that equals the remaining time until the impending 'event'. When the treatment completes, check if you've reached the 'event' time, and if you have do whatever you want to do, but if you haven't then play the next treatment specifying a timeout that equals the remaining time until the impending 'event', and so on.
------------------------------
Nick Tait
Genesys Consultant
Original Message:
Sent: 09-03-2025 11:48
From: Dave Halderman
Subject: Time Based Events in Architect
I just implemented a very rudimentary version of this. I have a main in-queue flow that is used for hold music and messaging. It looks up the timings and the prompts to play based on the current queue that the interaction is in. It may play 3 prompts in a sequence with hold music in between each, then repeat the loop.
For example, it may be using a sequence like:
holdMusicTime = [30, 30, 60]
prompts = [VaccineMessage, MyTCMessage, ThankYouForHolding]
In that case it would play hold music for 30 seconds, then play the first prompt, play music for another 30 seconds, play the second prompt, ...
It uses a loop to iterate through those timings and prompts, so I have a step in the loop that does totalWaitTime = totalWaitTime + holdMusicTime[loopIndex]. I then have a Decision step that watches for totalWaitTime to hit certain thresholds so I can offer a callback, transfer to a different queue, etc. Since I'm not taking the length of the prompts into account, it's not exact. I don't really need it to be for my case, though.
Edit: I just reread your original message and see that you specifically called out the variability in prompt length which causes your timing to be inaccurate. In that case, I probably didn't help very much. :D I'm subscribed to this thread to see if someone else has a better idea, though.
------------------------------
Dave Halderman
Business Analyst
Original Message:
Sent: 09-02-2025 04:49
From: Mihai Vasiloiu
Subject: Time Based Events in Architect
Hello,
nobody has any idea how could I achieve this?
Regards,
Mihai
------------------------------
Mihai Vasiloiu
Tech Lead Customer Interactions
Original Message:
Sent: 08-26-2025 11:40
From: Mihai Vasiloiu
Subject: Time Based Events in Architect
Hello,
is there a way in architect to trigger a functionality/flow based on a time event?
For example, I want to play a specific prompt or do an overflow if the customer is in the queue for 2 minutes already, and then another announcement after 5 minutes. In parallel the customer will hear the normal queue treatments. So I need an event to interrupt the normal queue flow and be able to execute another function.
I know that there a way is to calculate the treatments duration + music duration and call my function more or less after 2 minutes but the prompts and music are dynamic so the duration can vary a lot so it's not reliable.
In the On-Premise Genesys we had the Begin Parallel Block in Composer which could be used especially for cases like this.
Regards,
Mihai
#Architect
------------------------------
Mihai Vasiloiu
Tech Lead Customer Interactions
------------------------------