lasator | 2017-02-10 00:19:05 UTC | #1
It looks like setting the wrapup code for emails and chats created through the Limited Availability feature for third party media isn't being set properly. The wrapup code is actually being set on the participant. However, the wrapupRequired property of the participant continues to report a value of true. This is not the same behavior as a telephony interaction. Can you confirm that this is abnormal behavior?
rob.gevers | 2017-02-10 14:33:00 UTC | #2
This is the correct behavior and should also be the way voice interactions are behaving. If you have the id for an interaction where you see this not remaining true I can take a look at the scenario. So long as the agent has connected to the interaction (answered the alerting communication), the flag should be set to true and remain true.
lasator | 2017-02-10 18:24:36 UTC | #3
Is this a change in behavior from a previous release? I just retested telephony and am seeing the same thing. I actually have functionality built around the other behavior that was working correctly and is now currently broken.
So, is it now required to call https://api.{{environment}}/api/v2/conversations/{{mediatype}}/{{callbackId}}/participants/{participantId}/wrapup for every agent participant every time an event comes in to determine if that agent has applied a wrapup code to the interaction? That seems rather unfortunate and highly inefficient. This will probably incur at least 20 requests per call per agent.
Having the wrapupRequired property indicate if a wrapup code is actually required at the time of the event makes more sense.
tim.smith | 2017-02-10 18:57:33 UTC | #4
I've discussed this with Rob and have opened CS-780 to add the wrapup property to the participant in the conversation notification schema. Once that is resolved, you will be able to determine if the participant needs to wrap by checking for wrapupRequired==true && wrapup==undefined.
rob.gevers | 2017-02-10 19:04:41 UTC | #5
This isn't a change in behavior but it looks like the wrapup value isn't present in the v2 notification so we will get that added. Thanks for pointing that out.
lasator | 2017-02-10 19:07:21 UTC | #6
That would be great. Maybe there was a bug that I was inadvertently leveraging for that purpose that got fixed. Just my luck :slight_smile:
anon31479118 | 2017-02-10 19:27:18 UTC | #7
Thanks, Rob and Tim!
lasator | 2017-02-24 18:49:31 UTC | #8
I'm also noticing that when an interaction is rejected by the agent, the chat or email is being disconnected from the customer side. Shouldn't this place the interaction back into queue for the next available agent?
system | 2017-08-28 19:31:59 UTC | #9
This post was migrated from the old Developer Forum.
ref: 900