Genesys Cloud - Developer Community!

Hello,

Since Genesys support does not really help on this matter, i am opening a case in the developer forum, hoping someone else to have faced the same issue.

The flow i am building is:
Inbound Call -> Callback submitted by inbound call flow via Create Callback architect block -> Queue that callback is submitted is configured to use customer first callback -> Genesys Cloud dials a call -> Customer answers -> Call is routed to another inbound flow -> The flow offers two (2) choices to customer. Either wait in queue or reschedule the callback after specified amount of time. To expedite the callback reschedule i am using the following Genesys Cloud API call (/api/v2/conversations/${input.ConversationId}/participants/${input.ParticipantId}/callbacks).

And now is the weird part. The scheduled callback is created properly BUT after a small amount of time (1-2 minutes) conversation is terminated without any further dialing. In the timeline the last bar i can see is the Scheduled one.

Best Regards,
Orestis.

Hello Orestis,

I am going to move this across to the Genesys Cloud Developer Community to see if they can help on this.

Hello,

Since Genesys support does not really help on this matter, i am opening a case in the developer forum, hoping someone else to have faced the same issue.

The flow i am building is:
Inbound Call -> Callback submitted by inbound call flow via Create Callback architect block -> Queue that callback is submitted is configured to use customer first callback -> Genesys Cloud dials a call -> Customer answers -> Call is routed to another inbound flow -> The flow offers two (2) choices to customer. Either wait in queue or reschedule the callback after specified amount of time. To expedite the callback reschedule i am using the following Genesys Cloud API call (/api/v2/conversations/${input.ConversationId}/participants/${input.ParticipantId}/callbacks).

And now is the weird part. The scheduled callback is created properly BUT after a small amount of time (1-2 minutes) conversation is terminated without any further dialing. In the timeline the last bar i can see is the Scheduled one.

Best Regards,
Orestis.

Hi Orestis, I am not sure why you are using the specific API you mentioned. It is using the participant-id from the inbound call (which I believe it is the customer participant), and then once customer selects the "second" callback and you create it against the participant-id, customer disconnects that participant and if I understand it correctly when the callback is picked-up on the scheduled time, it does not find the specific participant as that has already disconnected. I may be wrong but I think you may be better to use POST /api/v2/conversations/callback API

Hello Orestis,

I am going to move this across to the Genesys Cloud Developer Community to see if they can help on this.

Hello,

Since Genesys support does not really help on this matter, i am opening a case in the developer forum, hoping someone else to have faced the same issue.

The flow i am building is:
Inbound Call -> Callback submitted by inbound call flow via Create Callback architect block -> Queue that callback is submitted is configured to use customer first callback -> Genesys Cloud dials a call -> Customer answers -> Call is routed to another inbound flow -> The flow offers two (2) choices to customer. Either wait in queue or reschedule the callback after specified amount of time. To expedite the callback reschedule i am using the following Genesys Cloud API call (/api/v2/conversations/${input.ConversationId}/participants/${input.ParticipantId}/callbacks).

And now is the weird part. The scheduled callback is created properly BUT after a small amount of time (1-2 minutes) conversation is terminated without any further dialing. In the timeline the last bar i can see is the Scheduled one.

Best Regards,
Orestis.

Hello Vineet,

Thank you for the reply.

I would prefer to use this API instead of  POST /api/v2/conversations/callback. The reason is quite simple:

- Using  POST /api/v2/conversations/callback a new conversation is created (a new interaction).

- Using POST  /api/v2/conversations/${input.ConversationId}/participants/${input.ParticipantId}/callbacks the callback is rescheduled within the same conversation.

"customer disconnects that participant and if I understand it correctly when the callback is picked-up on the scheduled time, it does not find the specific participant as that has already disconnected."

If that was the case i would expect conversation to be disconnected immediately. The behavior i noticed is that the rescheduled callback is submitted but it gets disconnected after some time (1-2 minutes).

Hi Orestis, I am not sure why you are using the specific API you mentioned. It is using the participant-id from the inbound call (which I believe it is the customer participant), and then once customer selects the "second" callback and you create it against the participant-id, customer disconnects that participant and if I understand it correctly when the callback is picked-up on the scheduled time, it does not find the specific participant as that has already disconnected. I may be wrong but I think you may be better to use POST /api/v2/conversations/callback API

Hello Orestis,

I am going to move this across to the Genesys Cloud Developer Community to see if they can help on this.

Hello,

Since Genesys support does not really help on this matter, i am opening a case in the developer forum, hoping someone else to have faced the same issue.

The flow i am building is:
Inbound Call -> Callback submitted by inbound call flow via Create Callback architect block -> Queue that callback is submitted is configured to use customer first callback -> Genesys Cloud dials a call -> Customer answers -> Call is routed to another inbound flow -> The flow offers two (2) choices to customer. Either wait in queue or reschedule the callback after specified amount of time. To expedite the callback reschedule i am using the following Genesys Cloud API call (/api/v2/conversations/${input.ConversationId}/participants/${input.ParticipantId}/callbacks).

And now is the weird part. The scheduled callback is created properly BUT after a small amount of time (1-2 minutes) conversation is terminated without any further dialing. In the timeline the last bar i can see is the Scheduled one.

Best Regards,
Orestis.

Not sure why 1-2 min but I think its because the participant you created the callback against is no longer active.
Can you confirm which participant-id you are using to create the callback ? Can you try the same steps but use the purpose=ACD participant-id instead.

Hello Vineet,

Thank you for the reply.

I would prefer to use this API instead of  POST /api/v2/conversations/callback. The reason is quite simple:

- Using  POST /api/v2/conversations/callback a new conversation is created (a new interaction).

- Using POST  /api/v2/conversations/${input.ConversationId}/participants/${input.ParticipantId}/callbacks the callback is rescheduled within the same conversation.

"customer disconnects that participant and if I understand it correctly when the callback is picked-up on the scheduled time, it does not find the specific participant as that has already disconnected."

If that was the case i would expect conversation to be disconnected immediately. The behavior i noticed is that the rescheduled callback is submitted but it gets disconnected after some time (1-2 minutes).

Hi Orestis, I am not sure why you are using the specific API you mentioned. It is using the participant-id from the inbound call (which I believe it is the customer participant), and then once customer selects the "second" callback and you create it against the participant-id, customer disconnects that participant and if I understand it correctly when the callback is picked-up on the scheduled time, it does not find the specific participant as that has already disconnected. I may be wrong but I think you may be better to use POST /api/v2/conversations/callback API

Hello Orestis,

I am going to move this across to the Genesys Cloud Developer Community to see if they can help on this.

Hello,

Since Genesys support does not really help on this matter, i am opening a case in the developer forum, hoping someone else to have faced the same issue.

The flow i am building is:
Inbound Call -> Callback submitted by inbound call flow via Create Callback architect block -> Queue that callback is submitted is configured to use customer first callback -> Genesys Cloud dials a call -> Customer answers -> Call is routed to another inbound flow -> The flow offers two (2) choices to customer. Either wait in queue or reschedule the callback after specified amount of time. To expedite the callback reschedule i am using the following Genesys Cloud API call (/api/v2/conversations/${input.ConversationId}/participants/${input.ParticipantId}/callbacks).

And now is the weird part. The scheduled callback is created properly BUT after a small amount of time (1-2 minutes) conversation is terminated without any further dialing. In the timeline the last bar i can see is the Scheduled one.

Best Regards,
Orestis.

I am using the customer participant.

I have already tried using other participant ids (like ACD) and the data action call fails. It seems you can only use a customer participant.

Not sure why 1-2 min but I think its because the participant you created the callback against is no longer active.
Can you confirm which participant-id you are using to create the callback ? Can you try the same steps but use the purpose=ACD participant-id instead.

Hello Vineet,

Thank you for the reply.

I would prefer to use this API instead of  POST /api/v2/conversations/callback. The reason is quite simple:

- Using  POST /api/v2/conversations/callback a new conversation is created (a new interaction).

- Using POST  /api/v2/conversations/${input.ConversationId}/participants/${input.ParticipantId}/callbacks the callback is rescheduled within the same conversation.

"customer disconnects that participant and if I understand it correctly when the callback is picked-up on the scheduled time, it does not find the specific participant as that has already disconnected."

If that was the case i would expect conversation to be disconnected immediately. The behavior i noticed is that the rescheduled callback is submitted but it gets disconnected after some time (1-2 minutes).

Hi Orestis, I am not sure why you are using the specific API you mentioned. It is using the participant-id from the inbound call (which I believe it is the customer participant), and then once customer selects the "second" callback and you create it against the participant-id, customer disconnects that participant and if I understand it correctly when the callback is picked-up on the scheduled time, it does not find the specific participant as that has already disconnected. I may be wrong but I think you may be better to use POST /api/v2/conversations/callback API

Hello Orestis,

I am going to move this across to the Genesys Cloud Developer Community to see if they can help on this.

Hello,

Since Genesys support does not really help on this matter, i am opening a case in the developer forum, hoping someone else to have faced the same issue.

The flow i am building is:
Inbound Call -> Callback submitted by inbound call flow via Create Callback architect block -> Queue that callback is submitted is configured to use customer first callback -> Genesys Cloud dials a call -> Customer answers -> Call is routed to another inbound flow -> The flow offers two (2) choices to customer. Either wait in queue or reschedule the callback after specified amount of time. To expedite the callback reschedule i am using the following Genesys Cloud API call (/api/v2/conversations/${input.ConversationId}/participants/${input.ParticipantId}/callbacks).

And now is the weird part. The scheduled callback is created properly BUT after a small amount of time (1-2 minutes) conversation is terminated without any further dialing. In the timeline the last bar i can see is the Scheduled one.

Best Regards,
Orestis.

Ah! did not realise that.

I just ran the API from developer centre with a bare minimum information, conversation-id, customer participant-id, queue-id, a specific date/time in future, for an already closed call, and the API ran successfully and created the callback. 
It would be good to see the data-action that you have created for the callback creation. Also can you just run the data-action in test mode and see if it works

I am using the customer participant.

I have already tried using other participant ids (like ACD) and the data action call fails. It seems you can only use a customer participant.

Not sure why 1-2 min but I think its because the participant you created the callback against is no longer active.
Can you confirm which participant-id you are using to create the callback ? Can you try the same steps but use the purpose=ACD participant-id instead.

Hello Vineet,

Thank you for the reply.

I would prefer to use this API instead of  POST /api/v2/conversations/callback. The reason is quite simple:

- Using  POST /api/v2/conversations/callback a new conversation is created (a new interaction).

- Using POST  /api/v2/conversations/${input.ConversationId}/participants/${input.ParticipantId}/callbacks the callback is rescheduled within the same conversation.

"customer disconnects that participant and if I understand it correctly when the callback is picked-up on the scheduled time, it does not find the specific participant as that has already disconnected."

If that was the case i would expect conversation to be disconnected immediately. The behavior i noticed is that the rescheduled callback is submitted but it gets disconnected after some time (1-2 minutes).

Hi Orestis, I am not sure why you are using the specific API you mentioned. It is using the participant-id from the inbound call (which I believe it is the customer participant), and then once customer selects the "second" callback and you create it against the participant-id, customer disconnects that participant and if I understand it correctly when the callback is picked-up on the scheduled time, it does not find the specific participant as that has already disconnected. I may be wrong but I think you may be better to use POST /api/v2/conversations/callback API

Hello Orestis,

I am going to move this across to the Genesys Cloud Developer Community to see if they can help on this.

Hello,

Since Genesys support does not really help on this matter, i am opening a case in the developer forum, hoping someone else to have faced the same issue.

The flow i am building is:
Inbound Call -> Callback submitted by inbound call flow via Create Callback architect block -> Queue that callback is submitted is configured to use customer first callback -> Genesys Cloud dials a call -> Customer answers -> Call is routed to another inbound flow -> The flow offers two (2) choices to customer. Either wait in queue or reschedule the callback after specified amount of time. To expedite the callback reschedule i am using the following Genesys Cloud API call (/api/v2/conversations/${input.ConversationId}/participants/${input.ParticipantId}/callbacks).

And now is the weird part. The scheduled callback is created properly BUT after a small amount of time (1-2 minutes) conversation is terminated without any further dialing. In the timeline the last bar i can see is the Scheduled one.

Best Regards,
Orestis.

Thank you for making this test.

Please find attached the exact data action configuration i am using.

I also tried the same scenario as you did. I picked a terminated conversation and invoked the data action. It worked just fine. The conversation revived without being disconnected after 1-2 minutes.

Maybe the issue lies exactly on that. In the real life scenario, once the data action is invoked, the conversation is still active. Customer is on his/her phone. The callback is scheduled via data action and the customer closes his/her phone. After some time (1-2 minutes) the conversation is terminated and the callback is never dialed.

Ah! did not realise that.

I just ran the API from developer centre with a bare minimum information, conversation-id, customer participant-id, queue-id, a specific date/time in future, for an already closed call, and the API ran successfully and created the callback. 
It would be good to see the data-action that you have created for the callback creation. Also can you just run the data-action in test mode and see if it works

I am using the customer participant.

I have already tried using other participant ids (like ACD) and the data action call fails. It seems you can only use a customer participant.

Not sure why 1-2 min but I think its because the participant you created the callback against is no longer active.
Can you confirm which participant-id you are using to create the callback ? Can you try the same steps but use the purpose=ACD participant-id instead.

Hello Vineet,

Thank you for the reply.

I would prefer to use this API instead of  POST /api/v2/conversations/callback. The reason is quite simple:

- Using  POST /api/v2/conversations/callback a new conversation is created (a new interaction).

- Using POST  /api/v2/conversations/${input.ConversationId}/participants/${input.ParticipantId}/callbacks the callback is rescheduled within the same conversation.

"customer disconnects that participant and if I understand it correctly when the callback is picked-up on the scheduled time, it does not find the specific participant as that has already disconnected."

If that was the case i would expect conversation to be disconnected immediately. The behavior i noticed is that the rescheduled callback is submitted but it gets disconnected after some time (1-2 minutes).

Hi Orestis, I am not sure why you are using the specific API you mentioned. It is using the participant-id from the inbound call (which I believe it is the customer participant), and then once customer selects the "second" callback and you create it against the participant-id, customer disconnects that participant and if I understand it correctly when the callback is picked-up on the scheduled time, it does not find the specific participant as that has already disconnected. I may be wrong but I think you may be better to use POST /api/v2/conversations/callback API

Hello Orestis,

I am going to move this across to the Genesys Cloud Developer Community to see if they can help on this.

Hello,

Since Genesys support does not really help on this matter, i am opening a case in the developer forum, hoping someone else to have faced the same issue.

The flow i am building is:
Inbound Call -> Callback submitted by inbound call flow via Create Callback architect block -> Queue that callback is submitted is configured to use customer first callback -> Genesys Cloud dials a call -> Customer answers -> Call is routed to another inbound flow -> The flow offers two (2) choices to customer. Either wait in queue or reschedule the callback after specified amount of time. To expedite the callback reschedule i am using the following Genesys Cloud API call (/api/v2/conversations/${input.ConversationId}/participants/${input.ParticipantId}/callbacks).

And now is the weird part. The scheduled callback is created properly BUT after a small amount of time (1-2 minutes) conversation is terminated without any further dialing. In the timeline the last bar i can see is the Scheduled one.

Best Regards,
Orestis.

attached in txt format.

Thank you for making this test.

Please find attached the exact data action configuration i am using.

I also tried the same scenario as you did. I picked a terminated conversation and invoked the data action. It worked just fine. The conversation revived without being disconnected after 1-2 minutes.

Maybe the issue lies exactly on that. In the real life scenario, once the data action is invoked, the conversation is still active. Customer is on his/her phone. The callback is scheduled via data action and the customer closes his/her phone. After some time (1-2 minutes) the conversation is terminated and the callback is never dialed.

Ah! did not realise that.

I just ran the API from developer centre with a bare minimum information, conversation-id, customer participant-id, queue-id, a specific date/time in future, for an already closed call, and the API ran successfully and created the callback. 
It would be good to see the data-action that you have created for the callback creation. Also can you just run the data-action in test mode and see if it works

I am using the customer participant.

I have already tried using other participant ids (like ACD) and the data action call fails. It seems you can only use a customer participant.

Not sure why 1-2 min but I think its because the participant you created the callback against is no longer active.
Can you confirm which participant-id you are using to create the callback ? Can you try the same steps but use the purpose=ACD participant-id instead.

Hello Vineet,

Thank you for the reply.

I would prefer to use this API instead of  POST /api/v2/conversations/callback. The reason is quite simple:

- Using  POST /api/v2/conversations/callback a new conversation is created (a new interaction).

- Using POST  /api/v2/conversations/${input.ConversationId}/participants/${input.ParticipantId}/callbacks the callback is rescheduled within the same conversation.

"customer disconnects that participant and if I understand it correctly when the callback is picked-up on the scheduled time, it does not find the specific participant as that has already disconnected."

If that was the case i would expect conversation to be disconnected immediately. The behavior i noticed is that the rescheduled callback is submitted but it gets disconnected after some time (1-2 minutes).

Hi Orestis, I am not sure why you are using the specific API you mentioned. It is using the participant-id from the inbound call (which I believe it is the customer participant), and then once customer selects the "second" callback and you create it against the participant-id, customer disconnects that participant and if I understand it correctly when the callback is picked-up on the scheduled time, it does not find the specific participant as that has already disconnected. I may be wrong but I think you may be better to use POST /api/v2/conversations/callback API

Hello Orestis,

I am going to move this across to the Genesys Cloud Developer Community to see if they can help on this.

Hello,

Since Genesys support does not really help on this matter, i am opening a case in the developer forum, hoping someone else to have faced the same issue.

The flow i am building is:
Inbound Call -> Callback submitted by inbound call flow via Create Callback architect block -> Queue that callback is submitted is configured to use customer first callback -> Genesys Cloud dials a call -> Customer answers -> Call is routed to another inbound flow -> The flow offers two (2) choices to customer. Either wait in queue or reschedule the callback after specified amount of time. To expedite the callback reschedule i am using the following Genesys Cloud API call (/api/v2/conversations/${input.ConversationId}/participants/${input.ParticipantId}/callbacks).

And now is the weird part. The scheduled callback is created properly BUT after a small amount of time (1-2 minutes) conversation is terminated without any further dialing. In the timeline the last bar i can see is the Scheduled one.

Best Regards,
Orestis.

Any ideas anyone? Has anybody tried the same?

attached in txt format.

Thank you for making this test.

Please find attached the exact data action configuration i am using.

I also tried the same scenario as you did. I picked a terminated conversation and invoked the data action. It worked just fine. The conversation revived without being disconnected after 1-2 minutes.

Maybe the issue lies exactly on that. In the real life scenario, once the data action is invoked, the conversation is still active. Customer is on his/her phone. The callback is scheduled via data action and the customer closes his/her phone. After some time (1-2 minutes) the conversation is terminated and the callback is never dialed.

Ah! did not realise that.

I just ran the API from developer centre with a bare minimum information, conversation-id, customer participant-id, queue-id, a specific date/time in future, for an already closed call, and the API ran successfully and created the callback. 
It would be good to see the data-action that you have created for the callback creation. Also can you just run the data-action in test mode and see if it works

I am using the customer participant.

I have already tried using other participant ids (like ACD) and the data action call fails. It seems you can only use a customer participant.

Not sure why 1-2 min but I think its because the participant you created the callback against is no longer active.
Can you confirm which participant-id you are using to create the callback ? Can you try the same steps but use the purpose=ACD participant-id instead.

Hello Vineet,

Thank you for the reply.

I would prefer to use this API instead of  POST /api/v2/conversations/callback. The reason is quite simple:

- Using  POST /api/v2/conversations/callback a new conversation is created (a new interaction).

- Using POST  /api/v2/conversations/${input.ConversationId}/participants/${input.ParticipantId}/callbacks the callback is rescheduled within the same conversation.

"customer disconnects that participant and if I understand it correctly when the callback is picked-up on the scheduled time, it does not find the specific participant as that has already disconnected."

If that was the case i would expect conversation to be disconnected immediately. The behavior i noticed is that the rescheduled callback is submitted but it gets disconnected after some time (1-2 minutes).

Hi Orestis, I am not sure why you are using the specific API you mentioned. It is using the participant-id from the inbound call (which I believe it is the customer participant), and then once customer selects the "second" callback and you create it against the participant-id, customer disconnects that participant and if I understand it correctly when the callback is picked-up on the scheduled time, it does not find the specific participant as that has already disconnected. I may be wrong but I think you may be better to use POST /api/v2/conversations/callback API

Hello Orestis,

I am going to move this across to the Genesys Cloud Developer Community to see if they can help on this.

Hello,

Since Genesys support does not really help on this matter, i am opening a case in the developer forum, hoping someone else to have faced the same issue.

The flow i am building is:
Inbound Call -> Callback submitted by inbound call flow via Create Callback architect block -> Queue that callback is submitted is configured to use customer first callback -> Genesys Cloud dials a call -> Customer answers -> Call is routed to another inbound flow -> The flow offers two (2) choices to customer. Either wait in queue or reschedule the callback after specified amount of time. To expedite the callback reschedule i am using the following Genesys Cloud API call (/api/v2/conversations/${input.ConversationId}/participants/${input.ParticipantId}/callbacks).

And now is the weird part. The scheduled callback is created properly BUT after a small amount of time (1-2 minutes) conversation is terminated without any further dialing. In the timeline the last bar i can see is the Scheduled one.

Best Regards,
Orestis.

Apologies did not reply earlier. So when you call the API from your process, what is the new scheduled date/time you setup ? I hope it is something in future, more than a few minutes in future. 
From the data-action I can't see anything wrong.

The only other question to ask is once the API is run, do you have a disconnect step in Architect following the API ?

Any ideas anyone? Has anybody tried the same?

attached in txt format.

Thank you for making this test.

Please find attached the exact data action configuration i am using.

I also tried the same scenario as you did. I picked a terminated conversation and invoked the data action. It worked just fine. The conversation revived without being disconnected after 1-2 minutes.

Maybe the issue lies exactly on that. In the real life scenario, once the data action is invoked, the conversation is still active. Customer is on his/her phone. The callback is scheduled via data action and the customer closes his/her phone. After some time (1-2 minutes) the conversation is terminated and the callback is never dialed.

Ah! did not realise that.

I just ran the API from developer centre with a bare minimum information, conversation-id, customer participant-id, queue-id, a specific date/time in future, for an already closed call, and the API ran successfully and created the callback. 
It would be good to see the data-action that you have created for the callback creation. Also can you just run the data-action in test mode and see if it works

I am using the customer participant.

I have already tried using other participant ids (like ACD) and the data action call fails. It seems you can only use a customer participant.

Not sure why 1-2 min but I think its because the participant you created the callback against is no longer active.
Can you confirm which participant-id you are using to create the callback ? Can you try the same steps but use the purpose=ACD participant-id instead.

Hello Vineet,

Thank you for the reply.

I would prefer to use this API instead of  POST /api/v2/conversations/callback. The reason is quite simple:

- Using  POST /api/v2/conversations/callback a new conversation is created (a new interaction).

- Using POST  /api/v2/conversations/${input.ConversationId}/participants/${input.ParticipantId}/callbacks the callback is rescheduled within the same conversation.

"customer disconnects that participant and if I understand it correctly when the callback is picked-up on the scheduled time, it does not find the specific participant as that has already disconnected."

If that was the case i would expect conversation to be disconnected immediately. The behavior i noticed is that the rescheduled callback is submitted but it gets disconnected after some time (1-2 minutes).

Hi Orestis, I am not sure why you are using the specific API you mentioned. It is using the participant-id from the inbound call (which I believe it is the customer participant), and then once customer selects the "second" callback and you create it against the participant-id, customer disconnects that participant and if I understand it correctly when the callback is picked-up on the scheduled time, it does not find the specific participant as that has already disconnected. I may be wrong but I think you may be better to use POST /api/v2/conversations/callback API

Hello Orestis,

I am going to move this across to the Genesys Cloud Developer Community to see if they can help on this.

Hello,

Since Genesys support does not really help on this matter, i am opening a case in the developer forum, hoping someone else to have faced the same issue.

The flow i am building is:
Inbound Call -> Callback submitted by inbound call flow via Create Callback architect block -> Queue that callback is submitted is configured to use customer first callback -> Genesys Cloud dials a call -> Customer answers -> Call is routed to another inbound flow -> The flow offers two (2) choices to customer. Either wait in queue or reschedule the callback after specified amount of time. To expedite the callback reschedule i am using the following Genesys Cloud API call (/api/v2/conversations/${input.ConversationId}/participants/${input.ParticipantId}/callbacks).

And now is the weird part. The scheduled callback is created properly BUT after a small amount of time (1-2 minutes) conversation is terminated without any further dialing. In the timeline the last bar i can see is the Scheduled one.

Best Regards,
Orestis.

Hello Vineet,

No worries. Thank you for the response. 

Yes when the API is run and the data action is executed, a voice message is played back to customer regarding successful or unsuccessful callback submit and then a disconnect block follows. It is either this that is triggered or the customer will hang up during message play.

Of course, the scheduled date/time is ahead of time (some minutes ahead actually). I believe if the time is in the past, an error is thrown.

Thanks.

Apologies did not reply earlier. So when you call the API from your process, what is the new scheduled date/time you setup ? I hope it is something in future, more than a few minutes in future. 
From the data-action I can't see anything wrong.

The only other question to ask is once the API is run, do you have a disconnect step in Architect following the API ?

Any ideas anyone? Has anybody tried the same?

attached in txt format.

Thank you for making this test.

Please find attached the exact data action configuration i am using.

I also tried the same scenario as you did. I picked a terminated conversation and invoked the data action. It worked just fine. The conversation revived without being disconnected after 1-2 minutes.

Maybe the issue lies exactly on that. In the real life scenario, once the data action is invoked, the conversation is still active. Customer is on his/her phone. The callback is scheduled via data action and the customer closes his/her phone. After some time (1-2 minutes) the conversation is terminated and the callback is never dialed.

Ah! did not realise that.

I just ran the API from developer centre with a bare minimum information, conversation-id, customer participant-id, queue-id, a specific date/time in future, for an already closed call, and the API ran successfully and created the callback. 
It would be good to see the data-action that you have created for the callback creation. Also can you just run the data-action in test mode and see if it works

I am using the customer participant.

I have already tried using other participant ids (like ACD) and the data action call fails. It seems you can only use a customer participant.

Not sure why 1-2 min but I think its because the participant you created the callback against is no longer active.
Can you confirm which participant-id you are using to create the callback ? Can you try the same steps but use the purpose=ACD participant-id instead.

Hello Vineet,

Thank you for the reply.

I would prefer to use this API instead of  POST /api/v2/conversations/callback. The reason is quite simple:

- Using  POST /api/v2/conversations/callback a new conversation is created (a new interaction).

- Using POST  /api/v2/conversations/${input.ConversationId}/participants/${input.ParticipantId}/callbacks the callback is rescheduled within the same conversation.

"customer disconnects that participant and if I understand it correctly when the callback is picked-up on the scheduled time, it does not find the specific participant as that has already disconnected."

If that was the case i would expect conversation to be disconnected immediately. The behavior i noticed is that the rescheduled callback is submitted but it gets disconnected after some time (1-2 minutes).

Hi Orestis, I am not sure why you are using the specific API you mentioned. It is using the participant-id from the inbound call (which I believe it is the customer participant), and then once customer selects the "second" callback and you create it against the participant-id, customer disconnects that participant and if I understand it correctly when the callback is picked-up on the scheduled time, it does not find the specific participant as that has already disconnected. I may be wrong but I think you may be better to use POST /api/v2/conversations/callback API

Hello Orestis,

I am going to move this across to the Genesys Cloud Developer Community to see if they can help on this.

Hello,

Since Genesys support does not really help on this matter, i am opening a case in the developer forum, hoping someone else to have faced the same issue.

The flow i am building is:
Inbound Call -> Callback submitted by inbound call flow via Create Callback architect block -> Queue that callback is submitted is configured to use customer first callback -> Genesys Cloud dials a call -> Customer answers -> Call is routed to another inbound flow -> The flow offers two (2) choices to customer. Either wait in queue or reschedule the callback after specified amount of time. To expedite the callback reschedule i am using the following Genesys Cloud API call (/api/v2/conversations/${input.ConversationId}/participants/${input.ParticipantId}/callbacks).

And now is the weird part. The scheduled callback is created properly BUT after a small amount of time (1-2 minutes) conversation is terminated without any further dialing. In the timeline the last bar i can see is the Scheduled one.

Best Regards,
Orestis.