Genesys Cloud - Main

Hi everyone,

I have a voice interaction that remained in the queue for 1:01 before the system disconnected it (the disconnect type shows as "system").
During this time, no agent was available in the queue, and the customer did not hang up either.

The in-queue flow is very basic-it contains a Transfer to ACD action inside a loop that attempts the transfer three times.
There is also a failure flag (triggered if the Transfer to ACD actions fail), but it is set to False, indicating that the action executed successfully.

My question is: why did the system disconnect the interaction after exactly 1:01, and how is this duration determined?

Hi Abdullah,

is there an error code for the disconnect (you can see it in the interactions report)? Did you take a look into the execution history of that call? That feature of architect is very useful sometimes.

Best regards
Christoph

Hi everyone,

I have a voice interaction that remained in the queue for 1:01 before the system disconnected it (the disconnect type shows as "system").
During this time, no agent was available in the queue, and the customer did not hang up either.

The in-queue flow is very basic-it contains a Transfer to ACD action inside a loop that attempts the transfer three times.
There is also a failure flag (triggered if the Transfer to ACD actions fail), but it is set to False, indicating that the action executed successfully.

My question is: why did the system disconnect the interaction after exactly 1:01, and how is this duration determined?

Hi Christoph,

Thank you for responding. The error code is not populated for this interaction. I'm attaching screenshots from the in-queue flow and the interaction timeline.

In-queue flow:

Interaction TimeLine:

Regards,

Abdullah

Hi Abdullah,

is there an error code for the disconnect (you can see it in the interactions report)? Did you take a look into the execution history of that call? That feature of architect is very useful sometimes.

Best regards
Christoph

Hi everyone,

I have a voice interaction that remained in the queue for 1:01 before the system disconnected it (the disconnect type shows as "system").
During this time, no agent was available in the queue, and the customer did not hang up either.

The in-queue flow is very basic-it contains a Transfer to ACD action inside a loop that attempts the transfer three times.
There is also a failure flag (triggered if the Transfer to ACD actions fail), but it is set to False, indicating that the action executed successfully.

My question is: why did the system disconnect the interaction after exactly 1:01, and how is this duration determined?

Hi Christoph,

Thank you for responding. The error code is not populated for this interaction. I'm attaching screenshots from the in-queue flow and the interaction timeline.

In-queue flow:

Interaction TimeLine:

Regards,

Abdullah

Hi Abdullah,

is there an error code for the disconnect (you can see it in the interactions report)? Did you take a look into the execution history of that call? That feature of architect is very useful sometimes.

Best regards
Christoph

Hi everyone,

I have a voice interaction that remained in the queue for 1:01 before the system disconnected it (the disconnect type shows as "system").
During this time, no agent was available in the queue, and the customer did not hang up either.

The in-queue flow is very basic-it contains a Transfer to ACD action inside a loop that attempts the transfer three times.
There is also a failure flag (triggered if the Transfer to ACD actions fail), but it is set to False, indicating that the action executed successfully.

My question is: why did the system disconnect the interaction after exactly 1:01, and how is this duration determined?

Hi Abdullah,

what is the intention of disconnecting in-queue at all? My inqueue-call-flows have no disconnect at the end.
But back to your question: I am not shure, how the duration of 1:01 is determined. Your three loops have no delay-timer or something like that. What do you want to achieve with your question?

Hi Christoph,

Thank you for responding. The error code is not populated for this interaction. I'm attaching screenshots from the in-queue flow and the interaction timeline.

In-queue flow:

Interaction TimeLine:

Regards,

Abdullah

Hi Abdullah,

is there an error code for the disconnect (you can see it in the interactions report)? Did you take a look into the execution history of that call? That feature of architect is very useful sometimes.

Best regards
Christoph

Hi everyone,

I have a voice interaction that remained in the queue for 1:01 before the system disconnected it (the disconnect type shows as "system").
During this time, no agent was available in the queue, and the customer did not hang up either.

The in-queue flow is very basic-it contains a Transfer to ACD action inside a loop that attempts the transfer three times.
There is also a failure flag (triggered if the Transfer to ACD actions fail), but it is set to False, indicating that the action executed successfully.

My question is: why did the system disconnect the interaction after exactly 1:01, and how is this duration determined?

Hi Christoph,

Thank you for the prompt response. A brief context around this, I have not designed the call flow, it was done before me. This issue was raised to me to check why the call did not requeue and got disconnected after 1:01 min. 

Do you think the disconnecting step should not be there if I want the call to remain in the queue, wait for the agent. 

Hi Abdullah,

what is the intention of disconnecting in-queue at all? My inqueue-call-flows have no disconnect at the end.
But back to your question: I am not shure, how the duration of 1:01 is determined. Your three loops have no delay-timer or something like that. What do you want to achieve with your question?

Hi Christoph,

Thank you for responding. The error code is not populated for this interaction. I'm attaching screenshots from the in-queue flow and the interaction timeline.

In-queue flow:

Interaction TimeLine:

Regards,

Abdullah

Hi Abdullah,

is there an error code for the disconnect (you can see it in the interactions report)? Did you take a look into the execution history of that call? That feature of architect is very useful sometimes.

Best regards
Christoph

Hi everyone,

I have a voice interaction that remained in the queue for 1:01 before the system disconnected it (the disconnect type shows as "system").
During this time, no agent was available in the queue, and the customer did not hang up either.

The in-queue flow is very basic-it contains a Transfer to ACD action inside a loop that attempts the transfer three times.
There is also a failure flag (triggered if the Transfer to ACD actions fail), but it is set to False, indicating that the action executed successfully.

My question is: why did the system disconnect the interaction after exactly 1:01, and how is this duration determined?

That loop is showing three times through the loop then Disconnect if that Transfer to ACD fails, so that's probably what is happening. You need to turn on Execution Data and see if you can reproduce it.

If you cannot reproduce, Support can look at back end logs and probably get a good idea of what happened.

Hi Christoph,

Thank you for the prompt response. A brief context around this, I have not designed the call flow, it was done before me. This issue was raised to me to check why the call did not requeue and got disconnected after 1:01 min. 

Do you think the disconnecting step should not be there if I want the call to remain in the queue, wait for the agent. 

Hi Abdullah,

what is the intention of disconnecting in-queue at all? My inqueue-call-flows have no disconnect at the end.
But back to your question: I am not shure, how the duration of 1:01 is determined. Your three loops have no delay-timer or something like that. What do you want to achieve with your question?

Hi Christoph,

Thank you for responding. The error code is not populated for this interaction. I'm attaching screenshots from the in-queue flow and the interaction timeline.

In-queue flow:

Interaction TimeLine:

Regards,

Abdullah

Hi Abdullah,

is there an error code for the disconnect (you can see it in the interactions report)? Did you take a look into the execution history of that call? That feature of architect is very useful sometimes.

Best regards
Christoph

Hi everyone,

I have a voice interaction that remained in the queue for 1:01 before the system disconnected it (the disconnect type shows as "system").
During this time, no agent was available in the queue, and the customer did not hang up either.

The in-queue flow is very basic-it contains a Transfer to ACD action inside a loop that attempts the transfer three times.
There is also a failure flag (triggered if the Transfer to ACD actions fail), but it is set to False, indicating that the action executed successfully.

My question is: why did the system disconnect the interaction after exactly 1:01, and how is this duration determined?

Hi George,

That was my initial assessment as well, but there is a flag for failure branch, which was not raised, so it is safe to say that interaction was Transferred to ACD all the times this action was executed. 

I was searching for any timeout settings ( if there is one ) for the flow or queue which disconnects the calls sitting in queue after a particular time, maybe on the edge device. Not sure about it though. 

I have turned on the execution history feature now and trying to reproduce the issue using a test flow. Will let you know my findings. 

Thank you for your response. 

That loop is showing three times through the loop then Disconnect if that Transfer to ACD fails, so that's probably what is happening. You need to turn on Execution Data and see if you can reproduce it.

If you cannot reproduce, Support can look at back end logs and probably get a good idea of what happened.

Hi Christoph,

Thank you for the prompt response. A brief context around this, I have not designed the call flow, it was done before me. This issue was raised to me to check why the call did not requeue and got disconnected after 1:01 min. 

Do you think the disconnecting step should not be there if I want the call to remain in the queue, wait for the agent. 

Hi Abdullah,

what is the intention of disconnecting in-queue at all? My inqueue-call-flows have no disconnect at the end.
But back to your question: I am not shure, how the duration of 1:01 is determined. Your three loops have no delay-timer or something like that. What do you want to achieve with your question?

Hi Christoph,

Thank you for responding. The error code is not populated for this interaction. I'm attaching screenshots from the in-queue flow and the interaction timeline.

In-queue flow:

Interaction TimeLine:

Regards,

Abdullah

Hi Abdullah,

is there an error code for the disconnect (you can see it in the interactions report)? Did you take a look into the execution history of that call? That feature of architect is very useful sometimes.

Best regards
Christoph

Hi everyone,

I have a voice interaction that remained in the queue for 1:01 before the system disconnected it (the disconnect type shows as "system").
During this time, no agent was available in the queue, and the customer did not hang up either.

The in-queue flow is very basic-it contains a Transfer to ACD action inside a loop that attempts the transfer three times.
There is also a failure flag (triggered if the Transfer to ACD actions fail), but it is set to False, indicating that the action executed successfully.

My question is: why did the system disconnect the interaction after exactly 1:01, and how is this duration determined?

I just took a closer look at the screenshots you posted, and realized that the disconnect at the 1:01 mark is a Transfer, not a call Disconnect...

Ehat happened after the Transfer? What do you see when you hover over the next two segments of the call right after the Transfer?

Hi George,

That was my initial assessment as well, but there is a flag for failure branch, which was not raised, so it is safe to say that interaction was Transferred to ACD all the times this action was executed. 

I was searching for any timeout settings ( if there is one ) for the flow or queue which disconnects the calls sitting in queue after a particular time, maybe on the edge device. Not sure about it though. 

I have turned on the execution history feature now and trying to reproduce the issue using a test flow. Will let you know my findings. 

Thank you for your response. 

That loop is showing three times through the loop then Disconnect if that Transfer to ACD fails, so that's probably what is happening. You need to turn on Execution Data and see if you can reproduce it.

If you cannot reproduce, Support can look at back end logs and probably get a good idea of what happened.

Hi Christoph,

Thank you for the prompt response. A brief context around this, I have not designed the call flow, it was done before me. This issue was raised to me to check why the call did not requeue and got disconnected after 1:01 min. 

Do you think the disconnecting step should not be there if I want the call to remain in the queue, wait for the agent. 

Hi Abdullah,

what is the intention of disconnecting in-queue at all? My inqueue-call-flows have no disconnect at the end.
But back to your question: I am not shure, how the duration of 1:01 is determined. Your three loops have no delay-timer or something like that. What do you want to achieve with your question?

Hi Christoph,

Thank you for responding. The error code is not populated for this interaction. I'm attaching screenshots from the in-queue flow and the interaction timeline.

In-queue flow:

Interaction TimeLine:

Regards,

Abdullah

Hi Abdullah,

is there an error code for the disconnect (you can see it in the interactions report)? Did you take a look into the execution history of that call? That feature of architect is very useful sometimes.

Best regards
Christoph

Hi everyone,

I have a voice interaction that remained in the queue for 1:01 before the system disconnected it (the disconnect type shows as "system").
During this time, no agent was available in the queue, and the customer did not hang up either.

The in-queue flow is very basic-it contains a Transfer to ACD action inside a loop that attempts the transfer three times.
There is also a failure flag (triggered if the Transfer to ACD actions fail), but it is set to False, indicating that the action executed successfully.

My question is: why did the system disconnect the interaction after exactly 1:01, and how is this duration determined?

Here it is.

I just took a closer look at the screenshots you posted, and realized that the disconnect at the 1:01 mark is a Transfer, not a call Disconnect...

Ehat happened after the Transfer? What do you see when you hover over the next two segments of the call right after the Transfer?

Hi George,

That was my initial assessment as well, but there is a flag for failure branch, which was not raised, so it is safe to say that interaction was Transferred to ACD all the times this action was executed. 

I was searching for any timeout settings ( if there is one ) for the flow or queue which disconnects the calls sitting in queue after a particular time, maybe on the edge device. Not sure about it though. 

I have turned on the execution history feature now and trying to reproduce the issue using a test flow. Will let you know my findings. 

Thank you for your response. 

That loop is showing three times through the loop then Disconnect if that Transfer to ACD fails, so that's probably what is happening. You need to turn on Execution Data and see if you can reproduce it.

If you cannot reproduce, Support can look at back end logs and probably get a good idea of what happened.

Hi Christoph,

Thank you for the prompt response. A brief context around this, I have not designed the call flow, it was done before me. This issue was raised to me to check why the call did not requeue and got disconnected after 1:01 min. 

Do you think the disconnecting step should not be there if I want the call to remain in the queue, wait for the agent. 

Hi Abdullah,

what is the intention of disconnecting in-queue at all? My inqueue-call-flows have no disconnect at the end.
But back to your question: I am not shure, how the duration of 1:01 is determined. Your three loops have no delay-timer or something like that. What do you want to achieve with your question?

Hi Christoph,

Thank you for responding. The error code is not populated for this interaction. I'm attaching screenshots from the in-queue flow and the interaction timeline.

In-queue flow:

Interaction TimeLine:

Regards,

Abdullah

Hi Abdullah,

is there an error code for the disconnect (you can see it in the interactions report)? Did you take a look into the execution history of that call? That feature of architect is very useful sometimes.

Best regards
Christoph

Hi everyone,

I have a voice interaction that remained in the queue for 1:01 before the system disconnected it (the disconnect type shows as "system").
During this time, no agent was available in the queue, and the customer did not hang up either.

The in-queue flow is very basic-it contains a Transfer to ACD action inside a loop that attempts the transfer three times.
There is also a failure flag (triggered if the Transfer to ACD actions fail), but it is set to False, indicating that the action executed successfully.

My question is: why did the system disconnect the interaction after exactly 1:01, and how is this duration determined?

I made a copy of the flow for testing, and made a test call with no agent waiting.

Results:

Transferred to ACD, the action was executed. The interaction went into the queue and waited for a 1:05 min, then got queued again and waited for the same time and so on. 

So in the test flow, the call is requeuing, but in the production flow, the call is not requeuing and disconnects. 

Just to add, I'm using Preferred agent routing for test and production flow, not sure if that makes a difference. 

Here it is.

I just took a closer look at the screenshots you posted, and realized that the disconnect at the 1:01 mark is a Transfer, not a call Disconnect...

Ehat happened after the Transfer? What do you see when you hover over the next two segments of the call right after the Transfer?

Hi George,

That was my initial assessment as well, but there is a flag for failure branch, which was not raised, so it is safe to say that interaction was Transferred to ACD all the times this action was executed. 

I was searching for any timeout settings ( if there is one ) for the flow or queue which disconnects the calls sitting in queue after a particular time, maybe on the edge device. Not sure about it though. 

I have turned on the execution history feature now and trying to reproduce the issue using a test flow. Will let you know my findings. 

Thank you for your response. 

That loop is showing three times through the loop then Disconnect if that Transfer to ACD fails, so that's probably what is happening. You need to turn on Execution Data and see if you can reproduce it.

If you cannot reproduce, Support can look at back end logs and probably get a good idea of what happened.

Hi Christoph,

Thank you for the prompt response. A brief context around this, I have not designed the call flow, it was done before me. This issue was raised to me to check why the call did not requeue and got disconnected after 1:01 min. 

Do you think the disconnecting step should not be there if I want the call to remain in the queue, wait for the agent. 

Hi Abdullah,

what is the intention of disconnecting in-queue at all? My inqueue-call-flows have no disconnect at the end.
But back to your question: I am not shure, how the duration of 1:01 is determined. Your three loops have no delay-timer or something like that. What do you want to achieve with your question?

Hi Christoph,

Thank you for responding. The error code is not populated for this interaction. I'm attaching screenshots from the in-queue flow and the interaction timeline.

In-queue flow:

Interaction TimeLine:

Regards,

Abdullah

Hi Abdullah,

is there an error code for the disconnect (you can see it in the interactions report)? Did you take a look into the execution history of that call? That feature of architect is very useful sometimes.

Best regards
Christoph

Hi everyone,

I have a voice interaction that remained in the queue for 1:01 before the system disconnected it (the disconnect type shows as "system").
During this time, no agent was available in the queue, and the customer did not hang up either.

The in-queue flow is very basic-it contains a Transfer to ACD action inside a loop that attempts the transfer three times.
There is also a failure flag (triggered if the Transfer to ACD actions fail), but it is set to False, indicating that the action executed successfully.

My question is: why did the system disconnect the interaction after exactly 1:01, and how is this duration determined?

I made a copy of the flow for testing, and made a test call with no agent waiting.

Results:

Transferred to ACD, the action was executed. The interaction went into the queue and waited for a 1:05 min, then got queued again and waited for the same time and so on. 

So in the test flow, the call is requeuing, but in the production flow, the call is not requeuing and disconnects. 

Just to add, I'm using Preferred agent routing for test and production flow, not sure if that makes a difference. 

Here it is.

I just took a closer look at the screenshots you posted, and realized that the disconnect at the 1:01 mark is a Transfer, not a call Disconnect...

Ehat happened after the Transfer? What do you see when you hover over the next two segments of the call right after the Transfer?

Hi George,

That was my initial assessment as well, but there is a flag for failure branch, which was not raised, so it is safe to say that interaction was Transferred to ACD all the times this action was executed. 

I was searching for any timeout settings ( if there is one ) for the flow or queue which disconnects the calls sitting in queue after a particular time, maybe on the edge device. Not sure about it though. 

I have turned on the execution history feature now and trying to reproduce the issue using a test flow. Will let you know my findings. 

Thank you for your response. 

That loop is showing three times through the loop then Disconnect if that Transfer to ACD fails, so that's probably what is happening. You need to turn on Execution Data and see if you can reproduce it.

If you cannot reproduce, Support can look at back end logs and probably get a good idea of what happened.

Hi Christoph,

Thank you for the prompt response. A brief context around this, I have not designed the call flow, it was done before me. This issue was raised to me to check why the call did not requeue and got disconnected after 1:01 min. 

Do you think the disconnecting step should not be there if I want the call to remain in the queue, wait for the agent. 

Hi Abdullah,

what is the intention of disconnecting in-queue at all? My inqueue-call-flows have no disconnect at the end.
But back to your question: I am not shure, how the duration of 1:01 is determined. Your three loops have no delay-timer or something like that. What do you want to achieve with your question?

Hi Christoph,

Thank you for responding. The error code is not populated for this interaction. I'm attaching screenshots from the in-queue flow and the interaction timeline.

In-queue flow:

Interaction TimeLine:

Regards,

Abdullah

Hi Abdullah,

is there an error code for the disconnect (you can see it in the interactions report)? Did you take a look into the execution history of that call? That feature of architect is very useful sometimes.

Best regards
Christoph

Hi everyone,

I have a voice interaction that remained in the queue for 1:01 before the system disconnected it (the disconnect type shows as "system").
During this time, no agent was available in the queue, and the customer did not hang up either.

The in-queue flow is very basic-it contains a Transfer to ACD action inside a loop that attempts the transfer three times.
There is also a failure flag (triggered if the Transfer to ACD actions fail), but it is set to False, indicating that the action executed successfully.

My question is: why did the system disconnect the interaction after exactly 1:01, and how is this duration determined?

The In-Queue flow is it trying to transfer to another queue while waiting in queue or is it trying to transfer it back to the same queue?

Don't know why you would have a loop there, as it should always succeed to transfer it to another queue.

I made a copy of the flow for testing, and made a test call with no agent waiting.

Results:

Transferred to ACD, the action was executed. The interaction went into the queue and waited for a 1:05 min, then got queued again and waited for the same time and so on. 

So in the test flow, the call is requeuing, but in the production flow, the call is not requeuing and disconnects. 

Just to add, I'm using Preferred agent routing for test and production flow, not sure if that makes a difference. 

Here it is.

I just took a closer look at the screenshots you posted, and realized that the disconnect at the 1:01 mark is a Transfer, not a call Disconnect...

Ehat happened after the Transfer? What do you see when you hover over the next two segments of the call right after the Transfer?

Hi George,

That was my initial assessment as well, but there is a flag for failure branch, which was not raised, so it is safe to say that interaction was Transferred to ACD all the times this action was executed. 

I was searching for any timeout settings ( if there is one ) for the flow or queue which disconnects the calls sitting in queue after a particular time, maybe on the edge device. Not sure about it though. 

I have turned on the execution history feature now and trying to reproduce the issue using a test flow. Will let you know my findings. 

Thank you for your response. 

That loop is showing three times through the loop then Disconnect if that Transfer to ACD fails, so that's probably what is happening. You need to turn on Execution Data and see if you can reproduce it.

If you cannot reproduce, Support can look at back end logs and probably get a good idea of what happened.

Hi Christoph,

Thank you for the prompt response. A brief context around this, I have not designed the call flow, it was done before me. This issue was raised to me to check why the call did not requeue and got disconnected after 1:01 min. 

Do you think the disconnecting step should not be there if I want the call to remain in the queue, wait for the agent. 

Hi Abdullah,

what is the intention of disconnecting in-queue at all? My inqueue-call-flows have no disconnect at the end.
But back to your question: I am not shure, how the duration of 1:01 is determined. Your three loops have no delay-timer or something like that. What do you want to achieve with your question?

Hi Christoph,

Thank you for responding. The error code is not populated for this interaction. I'm attaching screenshots from the in-queue flow and the interaction timeline.

In-queue flow:

Interaction TimeLine:

Regards,

Abdullah

Hi Abdullah,

is there an error code for the disconnect (you can see it in the interactions report)? Did you take a look into the execution history of that call? That feature of architect is very useful sometimes.

Best regards
Christoph

Hi everyone,

I have a voice interaction that remained in the queue for 1:01 before the system disconnected it (the disconnect type shows as "system").
During this time, no agent was available in the queue, and the customer did not hang up either.

The in-queue flow is very basic-it contains a Transfer to ACD action inside a loop that attempts the transfer three times.
There is also a failure flag (triggered if the Transfer to ACD actions fail), but it is set to False, indicating that the action executed successfully.

My question is: why did the system disconnect the interaction after exactly 1:01, and how is this duration determined?

Here is the complete timeline of the interaction.

Summary:

The interaction goes from the first in queue flow to the agent, where the agent picks the call. Eventually the agent blind transfers to another queue. The screenshot I pasted above is from the second in queue flow associated with another queue, in which the call waits for 1:01 min before system disconnects it.

Hope it makes sense. 

The In-Queue flow is it trying to transfer to another queue while waiting in queue or is it trying to transfer it back to the same queue?

Don't know why you would have a loop there, as it should always succeed to transfer it to another queue.

I made a copy of the flow for testing, and made a test call with no agent waiting.

Results:

Transferred to ACD, the action was executed. The interaction went into the queue and waited for a 1:05 min, then got queued again and waited for the same time and so on. 

So in the test flow, the call is requeuing, but in the production flow, the call is not requeuing and disconnects. 

Just to add, I'm using Preferred agent routing for test and production flow, not sure if that makes a difference. 

Here it is.

I just took a closer look at the screenshots you posted, and realized that the disconnect at the 1:01 mark is a Transfer, not a call Disconnect...

Ehat happened after the Transfer? What do you see when you hover over the next two segments of the call right after the Transfer?

Hi George,

That was my initial assessment as well, but there is a flag for failure branch, which was not raised, so it is safe to say that interaction was Transferred to ACD all the times this action was executed. 

I was searching for any timeout settings ( if there is one ) for the flow or queue which disconnects the calls sitting in queue after a particular time, maybe on the edge device. Not sure about it though. 

I have turned on the execution history feature now and trying to reproduce the issue using a test flow. Will let you know my findings. 

Thank you for your response. 

That loop is showing three times through the loop then Disconnect if that Transfer to ACD fails, so that's probably what is happening. You need to turn on Execution Data and see if you can reproduce it.

If you cannot reproduce, Support can look at back end logs and probably get a good idea of what happened.

Hi Christoph,

Thank you for the prompt response. A brief context around this, I have not designed the call flow, it was done before me. This issue was raised to me to check why the call did not requeue and got disconnected after 1:01 min. 

Do you think the disconnecting step should not be there if I want the call to remain in the queue, wait for the agent. 

Hi Abdullah,

what is the intention of disconnecting in-queue at all? My inqueue-call-flows have no disconnect at the end.
But back to your question: I am not shure, how the duration of 1:01 is determined. Your three loops have no delay-timer or something like that. What do you want to achieve with your question?

Hi Christoph,

Thank you for responding. The error code is not populated for this interaction. I'm attaching screenshots from the in-queue flow and the interaction timeline.

In-queue flow:

Interaction TimeLine:

Regards,

Abdullah

Hi Abdullah,

is there an error code for the disconnect (you can see it in the interactions report)? Did you take a look into the execution history of that call? That feature of architect is very useful sometimes.

Best regards
Christoph

Hi everyone,

I have a voice interaction that remained in the queue for 1:01 before the system disconnected it (the disconnect type shows as "system").
During this time, no agent was available in the queue, and the customer did not hang up either.

The in-queue flow is very basic-it contains a Transfer to ACD action inside a loop that attempts the transfer three times.
There is also a failure flag (triggered if the Transfer to ACD actions fail), but it is set to False, indicating that the action executed successfully.

My question is: why did the system disconnect the interaction after exactly 1:01, and how is this duration determined?

Hello,

Can you explain why there is a Transfer to ACD in the In-Queue flow?

I suspect this is causing the issue, and it seems kind of odd to have a in-queue flow that only contains a transfer to another queue.

Where does it try to transfer the call to?
The same queue it's already in?

Here is the complete timeline of the interaction.

Summary:

The interaction goes from the first in queue flow to the agent, where the agent picks the call. Eventually the agent blind transfers to another queue. The screenshot I pasted above is from the second in queue flow associated with another queue, in which the call waits for 1:01 min before system disconnects it.

Hope it makes sense. 

The In-Queue flow is it trying to transfer to another queue while waiting in queue or is it trying to transfer it back to the same queue?

Don't know why you would have a loop there, as it should always succeed to transfer it to another queue.

I made a copy of the flow for testing, and made a test call with no agent waiting.

Results:

Transferred to ACD, the action was executed. The interaction went into the queue and waited for a 1:05 min, then got queued again and waited for the same time and so on. 

So in the test flow, the call is requeuing, but in the production flow, the call is not requeuing and disconnects. 

Just to add, I'm using Preferred agent routing for test and production flow, not sure if that makes a difference. 

Here it is.

I just took a closer look at the screenshots you posted, and realized that the disconnect at the 1:01 mark is a Transfer, not a call Disconnect...

Ehat happened after the Transfer? What do you see when you hover over the next two segments of the call right after the Transfer?

Hi George,

That was my initial assessment as well, but there is a flag for failure branch, which was not raised, so it is safe to say that interaction was Transferred to ACD all the times this action was executed. 

I was searching for any timeout settings ( if there is one ) for the flow or queue which disconnects the calls sitting in queue after a particular time, maybe on the edge device. Not sure about it though. 

I have turned on the execution history feature now and trying to reproduce the issue using a test flow. Will let you know my findings. 

Thank you for your response. 

That loop is showing three times through the loop then Disconnect if that Transfer to ACD fails, so that's probably what is happening. You need to turn on Execution Data and see if you can reproduce it.

If you cannot reproduce, Support can look at back end logs and probably get a good idea of what happened.

Hi Christoph,

Thank you for the prompt response. A brief context around this, I have not designed the call flow, it was done before me. This issue was raised to me to check why the call did not requeue and got disconnected after 1:01 min. 

Do you think the disconnecting step should not be there if I want the call to remain in the queue, wait for the agent. 

Hi Abdullah,

what is the intention of disconnecting in-queue at all? My inqueue-call-flows have no disconnect at the end.
But back to your question: I am not shure, how the duration of 1:01 is determined. Your three loops have no delay-timer or something like that. What do you want to achieve with your question?

Hi Christoph,

Thank you for responding. The error code is not populated for this interaction. I'm attaching screenshots from the in-queue flow and the interaction timeline.

In-queue flow:

Interaction TimeLine:

Regards,

Abdullah

Hi Abdullah,

is there an error code for the disconnect (you can see it in the interactions report)? Did you take a look into the execution history of that call? That feature of architect is very useful sometimes.

Best regards
Christoph

Hi everyone,

I have a voice interaction that remained in the queue for 1:01 before the system disconnected it (the disconnect type shows as "system").
During this time, no agent was available in the queue, and the customer did not hang up either.

The in-queue flow is very basic-it contains a Transfer to ACD action inside a loop that attempts the transfer three times.
There is also a failure flag (triggered if the Transfer to ACD actions fail), but it is set to False, indicating that the action executed successfully.

My question is: why did the system disconnect the interaction after exactly 1:01, and how is this duration determined?

Per Jan's question - is that In-Queue Call flow transferring to a third queue, or transferring back to itself?

Hello,

Can you explain why there is a Transfer to ACD in the In-Queue flow?

I suspect this is causing the issue, and it seems kind of odd to have a in-queue flow that only contains a transfer to another queue.

Where does it try to transfer the call to?
The same queue it's already in?

Here is the complete timeline of the interaction.

Summary:

The interaction goes from the first in queue flow to the agent, where the agent picks the call. Eventually the agent blind transfers to another queue. The screenshot I pasted above is from the second in queue flow associated with another queue, in which the call waits for 1:01 min before system disconnects it.

Hope it makes sense. 

The In-Queue flow is it trying to transfer to another queue while waiting in queue or is it trying to transfer it back to the same queue?

Don't know why you would have a loop there, as it should always succeed to transfer it to another queue.

I made a copy of the flow for testing, and made a test call with no agent waiting.

Results:

Transferred to ACD, the action was executed. The interaction went into the queue and waited for a 1:05 min, then got queued again and waited for the same time and so on. 

So in the test flow, the call is requeuing, but in the production flow, the call is not requeuing and disconnects. 

Just to add, I'm using Preferred agent routing for test and production flow, not sure if that makes a difference. 

Here it is.

I just took a closer look at the screenshots you posted, and realized that the disconnect at the 1:01 mark is a Transfer, not a call Disconnect...

Ehat happened after the Transfer? What do you see when you hover over the next two segments of the call right after the Transfer?

Hi George,

That was my initial assessment as well, but there is a flag for failure branch, which was not raised, so it is safe to say that interaction was Transferred to ACD all the times this action was executed. 

I was searching for any timeout settings ( if there is one ) for the flow or queue which disconnects the calls sitting in queue after a particular time, maybe on the edge device. Not sure about it though. 

I have turned on the execution history feature now and trying to reproduce the issue using a test flow. Will let you know my findings. 

Thank you for your response. 

That loop is showing three times through the loop then Disconnect if that Transfer to ACD fails, so that's probably what is happening. You need to turn on Execution Data and see if you can reproduce it.

If you cannot reproduce, Support can look at back end logs and probably get a good idea of what happened.

Hi Christoph,

Thank you for the prompt response. A brief context around this, I have not designed the call flow, it was done before me. This issue was raised to me to check why the call did not requeue and got disconnected after 1:01 min. 

Do you think the disconnecting step should not be there if I want the call to remain in the queue, wait for the agent. 

Hi Abdullah,

what is the intention of disconnecting in-queue at all? My inqueue-call-flows have no disconnect at the end.
But back to your question: I am not shure, how the duration of 1:01 is determined. Your three loops have no delay-timer or something like that. What do you want to achieve with your question?

Hi Christoph,

Thank you for responding. The error code is not populated for this interaction. I'm attaching screenshots from the in-queue flow and the interaction timeline.

In-queue flow:

Interaction TimeLine:

Regards,

Abdullah

Hi Abdullah,

is there an error code for the disconnect (you can see it in the interactions report)? Did you take a look into the execution history of that call? That feature of architect is very useful sometimes.

Best regards
Christoph

Hi everyone,

I have a voice interaction that remained in the queue for 1:01 before the system disconnected it (the disconnect type shows as "system").
During this time, no agent was available in the queue, and the customer did not hang up either.

The in-queue flow is very basic-it contains a Transfer to ACD action inside a loop that attempts the transfer three times.
There is also a failure flag (triggered if the Transfer to ACD actions fail), but it is set to False, indicating that the action executed successfully.

My question is: why did the system disconnect the interaction after exactly 1:01, and how is this duration determined?

Thank you @Christoph Domaschke @Jan Heinonen @George Ganahl for responding. I have found the root cause. 

To answer your question, @George Ganahl, it is transferring back to itself. 

When the flow begins, there is a Get Participant action in place, which assigns the interaction language to a flow variable. But when the call is transferred to the ACD, the Language skill is not configured in the action. And the flow default language is not set, causing error in the flow, resulting in interaction disconnect as error handling for the flow is disconnect. 

So the interaction has a Language skill before the transfer to ACD, so it rings at the agent station in the first go, but disconnects when the flow is executed again. 

Hope this clarifies. Please let me know otherwise. 

Regards,

Sher

Per Jan's question - is that In-Queue Call flow transferring to a third queue, or transferring back to itself?

Hello,

Can you explain why there is a Transfer to ACD in the In-Queue flow?

I suspect this is causing the issue, and it seems kind of odd to have a in-queue flow that only contains a transfer to another queue.

Where does it try to transfer the call to?
The same queue it's already in?

Here is the complete timeline of the interaction.

Summary:

The interaction goes from the first in queue flow to the agent, where the agent picks the call. Eventually the agent blind transfers to another queue. The screenshot I pasted above is from the second in queue flow associated with another queue, in which the call waits for 1:01 min before system disconnects it.

Hope it makes sense. 

The In-Queue flow is it trying to transfer to another queue while waiting in queue or is it trying to transfer it back to the same queue?

Don't know why you would have a loop there, as it should always succeed to transfer it to another queue.

I made a copy of the flow for testing, and made a test call with no agent waiting.

Results:

Transferred to ACD, the action was executed. The interaction went into the queue and waited for a 1:05 min, then got queued again and waited for the same time and so on. 

So in the test flow, the call is requeuing, but in the production flow, the call is not requeuing and disconnects. 

Just to add, I'm using Preferred agent routing for test and production flow, not sure if that makes a difference. 

Here it is.

I just took a closer look at the screenshots you posted, and realized that the disconnect at the 1:01 mark is a Transfer, not a call Disconnect...

Ehat happened after the Transfer? What do you see when you hover over the next two segments of the call right after the Transfer?

Hi George,

That was my initial assessment as well, but there is a flag for failure branch, which was not raised, so it is safe to say that interaction was Transferred to ACD all the times this action was executed. 

I was searching for any timeout settings ( if there is one ) for the flow or queue which disconnects the calls sitting in queue after a particular time, maybe on the edge device. Not sure about it though. 

I have turned on the execution history feature now and trying to reproduce the issue using a test flow. Will let you know my findings. 

Thank you for your response. 

That loop is showing three times through the loop then Disconnect if that Transfer to ACD fails, so that's probably what is happening. You need to turn on Execution Data and see if you can reproduce it.

If you cannot reproduce, Support can look at back end logs and probably get a good idea of what happened.

Hi Christoph,

Thank you for the prompt response. A brief context around this, I have not designed the call flow, it was done before me. This issue was raised to me to check why the call did not requeue and got disconnected after 1:01 min. 

Do you think the disconnecting step should not be there if I want the call to remain in the queue, wait for the agent. 

Hi Abdullah,

what is the intention of disconnecting in-queue at all? My inqueue-call-flows have no disconnect at the end.
But back to your question: I am not shure, how the duration of 1:01 is determined. Your three loops have no delay-timer or something like that. What do you want to achieve with your question?

Hi Christoph,

Thank you for responding. The error code is not populated for this interaction. I'm attaching screenshots from the in-queue flow and the interaction timeline.

In-queue flow:

Interaction TimeLine:

Regards,

Abdullah

Hi Abdullah,

is there an error code for the disconnect (you can see it in the interactions report)? Did you take a look into the execution history of that call? That feature of architect is very useful sometimes.

Best regards
Christoph

Hi everyone,

I have a voice interaction that remained in the queue for 1:01 before the system disconnected it (the disconnect type shows as "system").
During this time, no agent was available in the queue, and the customer did not hang up either.

The in-queue flow is very basic-it contains a Transfer to ACD action inside a loop that attempts the transfer three times.
There is also a failure flag (triggered if the Transfer to ACD actions fail), but it is set to False, indicating that the action executed successfully.

My question is: why did the system disconnect the interaction after exactly 1:01, and how is this duration determined?

Thank you @Christoph Domaschke @Jan Heinonen @George Ganahl for responding. I have found the root cause. 

To answer your question, @George Ganahl, it is transferring back to itself. 

When the flow begins, there is a Get Participant action in place, which assigns the interaction language to a flow variable. But when the call is transferred to the ACD, the Language skill is not configured in the action. And the flow default language is not set, causing error in the flow, resulting in interaction disconnect as error handling for the flow is disconnect. 

So the interaction has a Language skill before the transfer to ACD, so it rings at the agent station in the first go, but disconnects when the flow is executed again. 

Hope this clarifies. Please let me know otherwise. 

Regards,

Sher

Per Jan's question - is that In-Queue Call flow transferring to a third queue, or transferring back to itself?

Hello,

Can you explain why there is a Transfer to ACD in the In-Queue flow?

I suspect this is causing the issue, and it seems kind of odd to have a in-queue flow that only contains a transfer to another queue.

Where does it try to transfer the call to?
The same queue it's already in?

Here is the complete timeline of the interaction.

Summary:

The interaction goes from the first in queue flow to the agent, where the agent picks the call. Eventually the agent blind transfers to another queue. The screenshot I pasted above is from the second in queue flow associated with another queue, in which the call waits for 1:01 min before system disconnects it.

Hope it makes sense. 

The In-Queue flow is it trying to transfer to another queue while waiting in queue or is it trying to transfer it back to the same queue?

Don't know why you would have a loop there, as it should always succeed to transfer it to another queue.

I made a copy of the flow for testing, and made a test call with no agent waiting.

Results:

Transferred to ACD, the action was executed. The interaction went into the queue and waited for a 1:05 min, then got queued again and waited for the same time and so on. 

So in the test flow, the call is requeuing, but in the production flow, the call is not requeuing and disconnects. 

Just to add, I'm using Preferred agent routing for test and production flow, not sure if that makes a difference. 

Here it is.

I just took a closer look at the screenshots you posted, and realized that the disconnect at the 1:01 mark is a Transfer, not a call Disconnect...

Ehat happened after the Transfer? What do you see when you hover over the next two segments of the call right after the Transfer?

Hi George,

That was my initial assessment as well, but there is a flag for failure branch, which was not raised, so it is safe to say that interaction was Transferred to ACD all the times this action was executed. 

I was searching for any timeout settings ( if there is one ) for the flow or queue which disconnects the calls sitting in queue after a particular time, maybe on the edge device. Not sure about it though. 

I have turned on the execution history feature now and trying to reproduce the issue using a test flow. Will let you know my findings. 

Thank you for your response. 

That loop is showing three times through the loop then Disconnect if that Transfer to ACD fails, so that's probably what is happening. You need to turn on Execution Data and see if you can reproduce it.

If you cannot reproduce, Support can look at back end logs and probably get a good idea of what happened.

Hi Christoph,

Thank you for the prompt response. A brief context around this, I have not designed the call flow, it was done before me. This issue was raised to me to check why the call did not requeue and got disconnected after 1:01 min. 

Do you think the disconnecting step should not be there if I want the call to remain in the queue, wait for the agent. 

Hi Abdullah,

what is the intention of disconnecting in-queue at all? My inqueue-call-flows have no disconnect at the end.
But back to your question: I am not shure, how the duration of 1:01 is determined. Your three loops have no delay-timer or something like that. What do you want to achieve with your question?

Hi Christoph,

Thank you for responding. The error code is not populated for this interaction. I'm attaching screenshots from the in-queue flow and the interaction timeline.

In-queue flow:

Interaction TimeLine:

Regards,

Abdullah

Hi Abdullah,

is there an error code for the disconnect (you can see it in the interactions report)? Did you take a look into the execution history of that call? That feature of architect is very useful sometimes.

Best regards
Christoph

Hi everyone,

I have a voice interaction that remained in the queue for 1:01 before the system disconnected it (the disconnect type shows as "system").
During this time, no agent was available in the queue, and the customer did not hang up either.

The in-queue flow is very basic-it contains a Transfer to ACD action inside a loop that attempts the transfer three times.
There is also a failure flag (triggered if the Transfer to ACD actions fail), but it is set to False, indicating that the action executed successfully.

My question is: why did the system disconnect the interaction after exactly 1:01, and how is this duration determined?