If you haven’t read my first post on Salesforce Service Cloud Voice, you can check it out here:
Salesforce Service Cloud Voice – Introduction and Setup
In that previous post, I mentioned that this product is powered by Amazon Connect and that Salesforce makes no attempt at hiding that. In fact, a lot of the phone system setup and configuration work is done directly on Amazon Web Services (AWS) management screens and not through some Salesforce wrapper. In this installment, we’ll look at the out-of-box “Sample SCV Inbound Flow With Transcription” flow in a lot more detail so that we can understand how a voice call originates on Amazon telephony infrastructure, snakes its way through various wormholes and eventually surfaces in a Salesforce Lightning App screen. How does a Voice Call record get created automatically? How does the live call transcription happen? How does all this magic work? Let’s find out. Open up the “Sample SCV Inbound Flow With Transcription” Contact Flow. You can do so from Salesforce by navigating to the list of your Contact Centers and clicking on the “Telephony Provider Settings” link.
This takes you over to Amazon Connect. Once there, you can find the “Contact Flows” menu item under the “Routing” section.
From the Call Flow listing, crack open the one entitled “Sample SCV Inbound Flow With Transcription”.
Sample SCV Inbound Flow With Transcription Call Flow
An initial look at the “Sample SCV Inbound Flow With Transcription” call-flow can be a bit overwhelming. So many boxes and connectors! But going through these, one by one, we can have a much better understanding of how things are connected and demystify the magical system. I’ll call out a few interesting boxes and their associated behaviors, below:
Set Contact Attributes: This widget allows you to set variables that you can then utilize in other parts of your Amazon Connect, for logging, propagate it to associated Lambda functions and then pass it further along, say, to your Salesforce instance.
The first instance of this you’ll see in the flow sets a variable named “REPLACEME” to a GUID. This GUID represents the default queue that was created for you when you provisioned this instance of Service Cloud Voice. You can confirm this by navigating to the Queues section of Amazon Connect, clicking on “BasicQueue” and checking out the ARN associated with this. The GUIDs should match. Also check out the “Set Working Queue” block within the call flow; you’ll see that the Queue is set to the value of this same variable.
You’ll see a few more instances of this “Set Contact Attributes” block. For example, one of these Set Contact Attributes widget is setting a variable named languageCode. In my instance, the value is “en-US“. This language setting is later used by other parts of the Contact Flow, for example, to allow the voice call transcription method to properly transcribe the call into text.
Invoke Lambda Function: Click on this block to get additional details. You’ll see that it is invoking a Lambda function named “InvokeTelephonyIntegrationApiFunction”. You’ll also note here that we are setting an input parameter for the invocation – methodName, the value of which is set to “createVoiceCall”.
Open a new tab in your browser and login to your AWS account associated with this, as the root user. Although you have access to Amazon Connect management screens by clicking on the Telephony Provider Settings link within Salesforce, you can’t access other portions of your AWS account using that method. Also, the authorization scope is limited to allowing you to manage your AWS Amazon Connect settings and using those credentials won’t allow you to access other things, like Lambda functions (like we are trying to do below). You must login as the root user (or as another user that you created, that has enough privileges) in order to do this. Once logged in, navigate to the Lambda functions section and you’ll see that Salesforce and Amazon has setup a handful of lambda functions, behind the scenes, when you created your Salesforce Service Cloud Voice Contact Center.
Among this list of functions, you’ll notice that there is one that’s named “InvokeTelephonyIntegrationApiFunction” which is what we saw the call flow invoking. Let’s take a peek at the code for this function. You can download the package and inspect the telephonyIntegrationApi.js file within it:
Sure enough, among the methods listed in this file, we find one named, createVoiceCall, which is what we saw in our call flow. A cursory review of this method yields the fact that it is making an API call out to an endpoint “/voiceCalls”, which as you may have already guessed is what created the Voice Call record, when a new call comes in.
Start Media Streaming: Streams the voice data over to the caller and back.
Transfer to Queue: This is the termination point for this Contact Flow, for the Happy Path. If no errors occurred, the call flow would eventually terminate here. We can pick up the trail by opening up the “Default Customer Queue” flow. In the default implementation, that flow is rather simple, playing a text-to-speech message, then switching over to some hold music and then repeating this sequence.
Parting Thoughts
This post hopefully peels another layer of the onion, showing some bridges between Amazon Connect and Salesforce in the form of Lambda function invocations and API calls. We were also able to trace and see where the text-to-speech prompts and hold music is being triggered; how the caller got placed into a default queue. We can geek out further over Kinesis and data-streams, trace how the voice data flows between the systems in a future installment.