I am trying to handle a situation described in this thread.

Background:

Our WhatsApp threading timeline is set to 72 hours. We have so far only supported web chat so allowing messages to come after hours is a new situation for us. We are concerned about sending after hours messages to a queue before the contact center opens because of the following reasons:

1. A large number of messages that came overnight could cause a longer wait for people who are contacting us just as the contact center opens (unless we use routing priority to prioritize interactions coming in live).
2. The overnight wait in queue would adversely affect our ability to analyze metrics.

We did initially consider using a dedicated after hours queue, and then have someone manually forward the messages to the correct queue (also suggested in that thread). We eventually settled on an approach that makes the manual step and the extra queue unncessary. We check if the contact center is closed. If so, we use a bot to tell the user that we are closed. We ask if they would like to proceed and let us know what they need and we will respond when the contact center is open, or would they like to disconnect now and try again when we are open.

If they choose to proceed then I have two nested loops in the messaging flow (not the inqueue flow). The inner loop has a maximum count of 99. I use a check schedule group action to see if the contact center will be open an hour from now. If not, I use the wait action to wait an hour and go to the next loop iteration. I keep iterating until the contact center is open. I then use a bot to send a message to say we are now open and ask if they are available. I send them to a queue when they say they are available.

Question

I want to make sure there are no surprises with this approach.

1. Are there any limitations about how many simultaneous flows we can have looping? I imagine the load would be similar to the load we have when we have multiple conversations going through a flow but I would like to make sure looping does not change anything.
2. Are there any limitations about how long a flow can loop? The other thread I reference has this information about email flows: 

   E-mail queue flows have a bit of an undocumented "issue" in that they only run for 72 hours, unless something has changed since I tested this a bit over a year ago.
   After that they will just stay in queue but don't process the queue flow.

   I encountered it when a customer wanted to have an overflow on e-mail after 5 days in queue and the overflow never happened.

   Another funny "feature" with e-mail queue flows is that it will start by running the Recurring State once every minute.
   After 5 runs it adds 5 seconds so it will now run every 1m 5s.

3. Are there any pricing implications?

Thanks for any help. I am happy to post details of this implementation if someone else is looking to do the same thing.

#ArchitectureandDesign
#DigitalChannels

------------------------------
Waqar Mahmood
Herbalife International of America, Inc.
------------------------------

Hi @Waqar Mahmood, 

Your question received an answer on the newest episode of the Genesys Cloud Q&A Show. Check the chapter markers to jump to your question. We hope this helps!