Service Cloud Voice Routing – Technical deep dive
How it works (under the covers)
The great thing about the upgrades for Routing of Service Cloud Voice that are GA in Spring is that it makes setup for Voice routing simpler and more powerful at the same time. It keeps all of the existing flexibility of Amazon, but enhances it with Salesforce data, and unifies it with other channels, such that the admin doesn’t need to worry about how it’s working in the back-end. What’s even better is that it’s all taken care of for us, so we just need to go into the Contact Center setup screen and point to the Routing rules.
But it’s interesting to know how it’s actually working, and I’ve seen quite a few folks wanting to understand more, so I thought I’d type up a quick post walking through the underlying details.
What’s been done is to deliver the best of both worlds, where the Routing Requirements (which queue does a call go into) are defined upfront inside Salesforce, while the Routing Execution (which agent in the Queue receives the call) is run inside Amazon.
When the call gets to the stage of doing the routing, the AWS Contact Flow invokes a dedicated routing API in Salesforce via Lambda (this is all pre-configured in a sub-flow for you), which runs the Omni Flow to get the routing requirements and returns a Queue ID to place the call into. There’s a queue mapping stored in Salesforce, pairing a Salesforce Queue to an equivalent Amazon queue which is what makes the whole thing work.
This allows the admin and supervisor to get a unified experience with all of their other channels, while the full power of the AWS connect system is still delivering the call in exactly the same way as before in the background.
Architecture
The below diagram shows the data flow across channels. The conversation (Email, Chat, Phone) first goes into its respective automation layer (IVR, Chatbot, Case Classification) before being passed to Omni where the business rules for routing and queues are defined.
For Voice, within Salesforce, three key things are synced to the back-end phone engine,
- The Agents presence (are they online for this channel or not)
- Capacity (does the agent have capacity to receive work or not)
- Routing requirements (where do we want to send the phone call)
With all of that info sent back, the phone engine can then determine which agent to deliver the call to and pass that request into Salesforce.
