Legacy Dev Forum Posts

T.Togashi | 2017-11-08 11:08:53 UTC | #1

Trying to create a PureCloud data action that will remove routing skill from user. I would like to call DELETE /api/v2/users/{userId}/routingskills/{skillId}, but in the Request configuration, if specified "DELETE" for requestType, the following error will occur. Invalid value 'DELETE' found for type: RequestType. Supported values are [PUT, POST, PATCH, GET] Why does data actions not support DELETE method? And is there any workaround?

Richard.Schott | 2017-11-08 13:42:26 UTC | #2

Data actions do not support the DELETE verb because we do not want the IVR used for the deletion of records in 3rd party systems (PureCloud public API is being accessed as if it were a 3rd party system). Given that the IVR integrations are often given elevated access permissions to the API resource they interface with, it doesn't seem prudent to allow it to have delete permissions to execute without ongoing oversight. In general, the usage of DELETE in APIs is also extremely rare, as deleting is a destructive operation that is not easily reversible.

I'd be curious to know exactly what you're trying to achieve by deleting a skill from a user within the IVR. It seems like the skill is being used as a proxy for something else, and that you're attempting to work around bulls-eye routing logic. Perhaps if we understood what you were trying to achieve, we could offer some other mechanism to get you there.

Thanks, Richard

T.Togashi | 2017-11-09 01:40:19 UTC | #3

OK, I understood the reason why data actions do not support the DELETE verb.

We need to transfer a call from a particular customer to a particular agent. If the agent can't receive the call, we want to be able to receive by other agents in queue. In order to realize this, we are considered below process.

1. When receiving call from the customer, acquire the user ID that we want to transfer with the external API.
2. We add specific routing skill to agent, and remove skill after ACD transfer.
3. If the agent can't receive the call, agents in the queue will be able to receive it with bulls-eye routing logic.

I don't think this is the best way, but I couldn't come up with a better way. If you have a better way please let me know.

Jason_Mathison | 2017-11-10 19:34:51 UTC | #4

I discussed this with our ACD group. Our suggestion is to use bullseye routing with the following approach:

Create a skill for each customer that has an assigned agent (or agents). Assign that skill to the appropriate agents. Assign the appropriate customer skill to calls from that customer. Add all of the customer skills to ring 1 of the bullseye routing configuration for the skill.

At that point calls with customer skills will try to route to their specialized agents first, or go to any agent if there is no customer skill. When the call leaves ring 1 it will remove all of the customer specific skills and be available for the wider agent population (or any other configuration choices that you make).

T.Togashi | 2017-11-13 06:59:20 UTC | #5

We considered that plan at first, but it was rejected from the viewpoint of maintainability. We have over 1,000,000 customers, and there is no way to dynamically assign a skill to calls in the Inbound Call Flow.

I will reconsider the feasibility of that plan by dynamically updating Inbound Call Flow with API POST /api/v2/flows/{flowId}/versions.

system | 2017-12-14 05:48:35 UTC | #6

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.

This post was migrated from the old Developer Forum.

ref: 2073