Service Cloud Voice Permissions and Security Explained
If you’re familiar with using Salesforce technologies to track customer data, keep a record of client feedback, and track previous interactions with your client base, then you might also be familiar with a platform called Service Cloud Voice.
If not, Service Cloud Voice is a combination of both the Amazon Connect platform to handle phone calls, and the Salesforce platform to handle CRM duties.
Essentially what this does for a business is two things:
- It streamlines the process of creating a fully integrated contact center software capable of saving your data and re-using it at a later time.
- It helps the business improve the quality of service by making its infrastructure highly resilient and highly available at all times. For some businesses, even a couple of minutes of downtime can come at a great cost
Great, so now what? How do we use Service Cloud Voice and is there anything special we need to do?
Well, the short answer is no! All you would have to do is contact a Salesforce representative so they can set up your instance. But, once the Salesforce environment is ready, another question appears – how does this all work? How do these two platforms communicate with each other?
In order for these platforms to communicate, AWS, or Amazon Web Services, requires that each service embedded into AWS have a set of permissions to access the services deployed into our Service Cloud Voice instance.
Service Cloud Voice Tenant Stack
So how is this all set up? Let’s start with what’s known as that Service Cloud Voice Tenant stack.
The Service Cloud Voice Tenant stack is a series of services deployed to our contact center that contain policies that give permission to those services to access other services within the same stack. This stack also gives our contact center the ability to write to databases deployed within the stack, create logs and save them for when they need to be accessed, and provide data to our contact center which is deployed in another AWS instance.
This stack consists of permission policies called roles, which are policies attached to certain serverless services to allow them to carry out their purpose as a service. A quick summary of each role:
- Contact Trace Record Role Policy: A policy that allows caller data to be synced from one platform to another. This role also gives our data sync function the ability to read and write data from Salesforce and other resources deployed in AWS, such as CloudWatch logs–a very important feature for storing data to gain insight into business trends.
- Contact Lens Consumer Role Policy: Contact lens is a resource that analyzes speech data and gathers insights based on that data. Things like customer feedback, contextualizing the sentiment behind the conversation, and categorizing contacts. This role gives Contact lens the ability to log all of this data to CloudWatch logs and trigger other functions within Service Cloud Voice.
- Contact Lens Streaming Role Policy: This role has the same permissions as the Contact lens function policy, but this role allows Contact Lens to log multiple streams of data to and from Salesforce on multiple call instances.
- Identity Provider Lambda Policy: This is a policy that allows our Identity Provider serverless function to create users that will be able to access our contact center. This policy also provides an Identity Provider ID number so that our provider can be identified when the user is created.
- Invoke Salesforce API Role: This policy can be attached to a resource in AWS which allows it to get, write, and read SSM parameters (keys that are required to access certain services, such as databases or digital storage spaces) on all services throughout AWS. This role also gives the invoke Salesforce API function write permissions to CloudWatch logs.
- Invoke Telephony Integration API Role: This allows our Amazon Connect instance to be used within our Salesforce instance. This is used to accept, reject, and queue calls as you would in a regular contact center. The policy gives the same permissions as the InvokeSalesforceRestApiFunctionRolePolicy resource, which allows the reading and writing of SSM parameters. This role also gives permission to write to CloudWatch logs.
- KVS Consumer Trigger Role Policy: This is a policy attached to the service that triggers the transcription of a call. This policy allows for the invocation of async and synchronous Lambda functions from all resources in AWS as well as creating logs in CloudWatch logs.
- KVS Transcriber Role Policy: This policy gives permission to the KVS transcriber to pull the call in Amazon Connect and transcribe it. This role gives permissions to read and write cloud logs, delete transcriptions, filter transcriptions from sensitive data, list which words are being filtered, and of course, initialize the transcription service itself. This role also holds permissions for obtaining video from Kinesis as well. This role gives permission to read and list SSM parameters and update contact information in Amazon Connect.
- Provisioning Role Resource: This role is more of an Admin role in AWS. This role is a general policy that allows the assigned user to provide any and all resources for the following services: Amazon Connect, Lambda, S3, Kinesis, CloudFormation, SSM, IAM, Secrets Manager, DS, KMS, CloudWatch Events, SNS, General CloudWatch, CloudWatch logs, and CloudTrail.
- S3 Role Policy: This role allows our S3 buckets (digital storage) to get objects, list other S3 buckets, and decrypt KMS keys. This role also comes with an assigned ID to refer to that specific bucket in which the role is being defined. This goes for all resources within AWS no matter where the data is coming from.
- SSM Lambda Execution Role Resource: This role allows our Lambdas to handle any action as it pertains to our SSM service. This role also allows Lambda to create and write CloudWatch log streams and events. This role also comes with a Sid which refers to the specific Lambda this role is assigned to. This is allowed from all resources on AWS.
- Trail Log Group Role Policy: This role consists of a CloudTrail policy that allows CloudTrail to write events, create log streams, and push those logs to the specified log group located in the N. Virginia us-east-1 Availability Zone in AWS.
In a nutshell, the Service Cloud Voice Tenant Stack is deployed before any other stack. This is because the permissions and roles need to be attached to the other contact center resources once they are deployed.
If you have an AWS account, you view these resources deployed in the IAM and S3 services section.
This is the beginning stage of when we initially activate our Service Cloud Voice instance through Salesforce. This graph may simplify the order in which our platform is deployed.
This graph only represents one part of how our Service Cloud Voice application is built and how permissions are shared between services in the application. But this piece is essentially about learning how these services can connect and share information, which might be the most meaningful part of using Service Cloud Voice as a contact center/ CRM Solution.
Service Cloud Voice is the “one-stop shop” platform for any business looking to implement a cost-effective, full-stack contact center web application capable of storing large amounts of data, transcribing and saving call information, tracking metrics for enhanced insight into customer issues, and so much more!
