Hello
Vaun,
Correct, the participant data will stay on the call object even after the call has been disconnected. You'll need to set the participant data in the
IVR flow to identify a none-
transferred call (as the
transferred callls go directly into the queue) and after you have your logic in the in-queue flow executed for none-
transferred calls you'll need to update the participant data. The update in the in-queue is needed just in case the none-
transferred call would be
transferred by an agent to a queue. Else the system will think that it's a none-
transferred call as the participant data has a specific value set.
Do you think this solution would solve your problem?
------------------------------
Dieter Wijnen
Telenet BVBA
------------------------------
Original Message:
Sent: 08-27-2020 03:38
From: Vaun McCarthy
Subject: Is there a way to tell in an in-queue flow if the call is a consult?
Thanks Dieter
I have a feeling that any participant data added within the IVR is going to still be there all the way through to the in-queue call flow.
------------------------------
Vaun McCarthy
NTT New Zealand Limited
------------------------------
Original Message:
Sent: 08-27-2020 02:30
From: Dieter Wijnen
Subject: Is there a way to tell in an in-queue flow if the call is a consult?
Hello Vaun,
I had a quick look into the properties set on a call and I do not see anything that you can use to identify if a call is part of a consult/blind transfer.
The consult/blind transfers are directly into the queue? And the other calls first pass an IVR flow before being assigned to the ACD Queue? If this is the case you can set some participant data in the IVR flow and verify in your In-Queue flow if this is set. If so, the call is not a transfer.
Kind regards,
Dieter
------------------------------
Dieter Wijnen
Telenet BVBA