Unless something has changed since I tested this back in July there are some undocumented quirks with the Recurring State in In-Queue Flows which wasn't mentioned.

The Recurring State start with running every 60 seconds, after 5 times it adds 5 seconds so it is now run every 65 seconds. After a few times it also reduces the number of runs required to add more time between each loop and eventually the Recurring State will only run once every 60 minutes.

Another important thing to know is that after 72 hours the Recurring State won't run at all, the e-mail will just wait in queue until an agent becomes available.
Started looking into how this actually worked after a customer wanted to overflow an e-mail after 5 days but it never happened.

Hi Jan,

I would like to know if you had any more details around the email overflow and how you solve this issue? Would it be possible to use recurring state to overflow an email to another queue after x days?

Thank you.

Unless something has changed since I tested this back in July there are some undocumented quirks with the Recurring State in In-Queue Flows which wasn't mentioned.

The Recurring State start with running every 60 seconds, after 5 times it adds 5 seconds so it is now run every 65 seconds. After a few times it also reduces the number of runs required to add more time between each loop and eventually the Recurring State will only run once every 60 minutes.

Another important thing to know is that after 72 hours the Recurring State won't run at all, the e-mail will just wait in queue until an agent becomes available.
Started looking into how this actually worked after a customer wanted to overflow an e-mail after 5 days but it never happened.

Hi,

Well, it depends  :)

If you want it to overflow within 72 hours, then you can do it in the recurring state.

If you want to wait longer than that before overflow, then I had the following idea that I haven't tested, since each test would take 3 days :)

Before the 72 hour limit, you would transfer the e-mail to the queue again, in theory that should reset the timers.

But you would also need to store in a variable, of how long the e-mail actually have waited in total and add priority based on that so it doesn't end up in the back of the queue again. Same variable can be used to decide when it's time to overflow the e-mail.

Hi Jan,

I would like to know if you had any more details around the email overflow and how you solve this issue? Would it be possible to use recurring state to overflow an email to another queue after x days?

Thank you.

Unless something has changed since I tested this back in July there are some undocumented quirks with the Recurring State in In-Queue Flows which wasn't mentioned.

The Recurring State start with running every 60 seconds, after 5 times it adds 5 seconds so it is now run every 65 seconds. After a few times it also reduces the number of runs required to add more time between each loop and eventually the Recurring State will only run once every 60 minutes.

Another important thing to know is that after 72 hours the Recurring State won't run at all, the e-mail will just wait in queue until an agent becomes available.
Started looking into how this actually worked after a customer wanted to overflow an e-mail after 5 days but it never happened.

Thanks a lot Jan, appreciate your prompt reply. I will test out your idea above :)

Hi,

Well, it depends  :)

If you want it to overflow within 72 hours, then you can do it in the recurring state.

If you want to wait longer than that before overflow, then I had the following idea that I haven't tested, since each test would take 3 days :)

Before the 72 hour limit, you would transfer the e-mail to the queue again, in theory that should reset the timers.

But you would also need to store in a variable, of how long the e-mail actually have waited in total and add priority based on that so it doesn't end up in the back of the queue again. Same variable can be used to decide when it's time to overflow the e-mail.

Hi Jan,

I would like to know if you had any more details around the email overflow and how you solve this issue? Would it be possible to use recurring state to overflow an email to another queue after x days?

Thank you.

Unless something has changed since I tested this back in July there are some undocumented quirks with the Recurring State in In-Queue Flows which wasn't mentioned.

The Recurring State start with running every 60 seconds, after 5 times it adds 5 seconds so it is now run every 65 seconds. After a few times it also reduces the number of runs required to add more time between each loop and eventually the Recurring State will only run once every 60 minutes.

Another important thing to know is that after 72 hours the Recurring State won't run at all, the e-mail will just wait in queue until an agent becomes available.
Started looking into how this actually worked after a customer wanted to overflow an e-mail after 5 days but it never happened.

Hi Cincin

Have you tested this idea ? pls let me know 

Regards

Halesha sn

Thanks a lot Jan, appreciate your prompt reply. I will test out your idea above :)

Hi,

Well, it depends  :)

If you want it to overflow within 72 hours, then you can do it in the recurring state.

If you want to wait longer than that before overflow, then I had the following idea that I haven't tested, since each test would take 3 days :)

Before the 72 hour limit, you would transfer the e-mail to the queue again, in theory that should reset the timers.

But you would also need to store in a variable, of how long the e-mail actually have waited in total and add priority based on that so it doesn't end up in the back of the queue again. Same variable can be used to decide when it's time to overflow the e-mail.

Hi Jan,

I would like to know if you had any more details around the email overflow and how you solve this issue? Would it be possible to use recurring state to overflow an email to another queue after x days?

Thank you.

Unless something has changed since I tested this back in July there are some undocumented quirks with the Recurring State in In-Queue Flows which wasn't mentioned.

The Recurring State start with running every 60 seconds, after 5 times it adds 5 seconds so it is now run every 65 seconds. After a few times it also reduces the number of runs required to add more time between each loop and eventually the Recurring State will only run once every 60 minutes.

Another important thing to know is that after 72 hours the Recurring State won't run at all, the e-mail will just wait in queue until an agent becomes available.
Started looking into how this actually worked after a customer wanted to overflow an e-mail after 5 days but it never happened.