Amazon Connect et Salesforce : qui détient la clé ?

Explication des autorisations et de la sécurité de Service Cloud Voice

Si vous êtes habitué à utiliser les technologies Salesforce pour suivre les données des clients, conserver un enregistrement des commentaires des clients et suivre les interactions précédentes avec votre clientèle, vous connaissez peut-être également une plate-forme appelée Voix en nuage de services.

Si ce n’est pas le cas, Service Cloud Voice est une combinaison des deux Connexion Amazon plate-forme pour gérer les appels téléphoniques, et la Force de vente plate-forme pour gérer les tâches CRM.

Ce que cela fait essentiellement pour une entreprise est deux choses :

• Il rationalise le processus de création d’un logiciel de centre de contact entièrement intégré capable de sauvegarder vos données et de les réutiliser ultérieurement.
• Il aide l’entreprise à améliorer la qualité de service en rendant son infrastructure hautement résiliente et hautement disponible à tout moment. Pour certaines entreprises, même quelques minutes d’indisponibilité peuvent coûter très cher

Super, et maintenant ? Comment utilisons-nous Service Cloud Voice et y a-t-il quelque chose de spécial que nous devons faire ?

Eh bien, la réponse courte est non ! Tout ce que vous auriez à faire est de contacter un représentant Salesforce afin qu’il puisse configurer votre instance. Mais, une fois que l’environnement Salesforce est prêt, une autre question apparaît : comment tout cela fonctionne-t-il ? Comment ces deux plateformes communiquent-elles entre elles ?

Pour que ces plateformes communiquent, AWS, ou alors Amazon Web Services, exige que chaque service intégré à AWS dispose d’un ensemble d’autorisations pour accéder aux services déployés dans notre instance Service Cloud Voice.

Pile de locataires Service Cloud Voice

Alors, comment tout cela est-il mis en place ? Commençons par ce qu’on appelle ça Pile de locataires Service Cloud Voice.

La pile Service Cloud Voice Tenant est une série de services déployés dans notre centre de contact qui contiennent des politiques qui autorisent ces services à accéder à d’autres services au sein de la même pile. Cette pile donne également à notre centre de contact la possibilité d’écrire dans des bases de données déployées au sein de la pile, de créer des journaux et de les enregistrer lorsqu’ils doivent y accéder, et de fournir des données à notre centre de contact qui est déployé dans une autre instance AWS.

Cette pile se compose de règles d’autorisation appelées rôles, qui sont des politiques attachées à certains services sans serveur pour leur permettre de réaliser leur objectif en tant que service. Un résumé rapide de chaque rôle :

• Politique de rôle d’enregistrement de trace de contact : une politique qui permet de synchroniser les données de l’appelant d’une plate-forme à l’autre. Ce rôle donne également à notre fonction de synchronisation des données la possibilité de lire et d’écrire des données à partir de Salesforce et d’autres ressources déployées dans AWS, telles que les journaux CloudWatch, une fonctionnalité très importante pour le stockage des données afin d’avoir un aperçu des tendances commerciales.
• Politique sur le rôle des consommateurs de lentilles de contact : les lentilles de contact sont une ressource qui analyse les données de parole et recueille des informations sur la base de ces données. Des choses comme les commentaires des clients, la contextualisation du sentiment derrière la conversation et la catégorisation des contacts. Ce rôle donne à Contact lens la possibilité de consigner toutes ces données dans les journaux CloudWatch et de déclencher d’autres fonctions dans Service Cloud Voice.
• Politique de rôle de diffusion de lentilles de contact : ce rôle dispose des mêmes autorisations que la politique de fonction de lentilles de contact, mais ce rôle permet à Contact Lens de consigner plusieurs flux de données vers et depuis Salesforce sur plusieurs instances d’appel.
• Politique Lambda du fournisseur d’identité : il s’agit d’une politique qui permet à notre fonction sans serveur de fournisseur d’identité de créer des utilisateurs qui pourront accéder à notre centre de contact. Cette politique fournit également un numéro d’identification de fournisseur d’identité afin que notre fournisseur puisse être identifié lors de la création de l’utilisateur.
• Invoke Salesforce API Role : cette politique peut être attachée à une ressource dans AWS qui lui permet d’obtenir, d’écrire et de lire les paramètres SSM (clés nécessaires pour accéder à certains services, tels que les bases de données ou les espaces de stockage numérique) sur tous les services d’AWS . Ce rôle accorde également à la fonction d’appel de l’API Salesforce des autorisations d’écriture sur les journaux CloudWatch.
• Appeler le rôle d’API d’intégration de la téléphonie : cela permet à notre instance Amazon Connect d’être utilisée dans notre instance Salesforce. Ceci est utilisé pour accepter, rejeter et mettre en file d’attente les appels comme vous le feriez dans un centre de contact ordinaire. La stratégie accorde les mêmes autorisations que InvokeSalesforceRestApiFunctionRolePolicy ressource, qui permet la lecture et l’écriture des paramètres SSM. Ce rôle donne également l’autorisation d’écrire dans les journaux CloudWatch.
• Politique de rôle de déclencheur du consommateur KVS : il s’agit d’une politique attachée au service qui déclenche la transcription d’un appel. Cette stratégie permet l’appel de fonctions Lambda asynchrones et synchrones à partir de toutes les ressources dans AWS ainsi que la création de journaux dans les journaux CloudWatch.
• Politique de rôle de transcripteur KVS : cette politique autorise le transcripteur KVS à extraire l’appel dans Amazon Connect et à le transcrire. Ce rôle permet de lire et d’écrire des journaux cloud, de supprimer des transcriptions, de filtrer les transcriptions à partir de données sensibles, de répertorier les mots filtrés et, bien sûr, d’initialiser le service de transcription lui-même. Ce rôle détient également des autorisations pour obtenir des vidéos de Kinesis. Ce rôle donne l’autorisation de lire et de répertorier les paramètres SSM et de mettre à jour les informations de contact dans Amazon Connect.
• Ressource de rôle d’approvisionnement : ce rôle est davantage un rôle d’administrateur dans AWS. Ce rôle est une stratégie générale qui permet à l’utilisateur affecté de fournir toutes les ressources pour les services suivants : Amazon Connect, Lambda, S3, Kinesis, CloudFormation, SSM, IAM, Secrets Manager, DS, KMS, CloudWatch Events, SNS, Général CloudWatch, journaux CloudWatch et CloudTrail.
• Politique de rôle S3 : ce rôle permet à nos compartiments S3 (stockage numérique) d’obtenir des objets, de répertorier d’autres compartiments S3 et de déchiffrer les clés KMS. Ce rôle est également fourni avec un ID attribué pour faire référence à ce compartiment spécifique dans lequel le rôle est défini. Cela vaut pour toutes les ressources d’AWS, quelle que soit la provenance des données.
• Ressource de rôle d’exécution SSM Lambda : ce rôle permet à nos Lambdas de gérer toute action en rapport avec notre service SSM. Ce rôle permet également à Lambda de créer et d’écrire des flux de journaux et des événements CloudWatch. Ce rôle est également fourni avec un Sid qui fait référence à la Lambda spécifique à laquelle ce rôle est attribué. Ceci est autorisé à partir de toutes les ressources sur AWS.
• Stratégie de rôle de groupe de journaux de piste : ce rôle consiste en une stratégie CloudTrail qui permet à CloudTrail d’écrire des événements, de créer des flux de journaux et de transmettre ces journaux au groupe de journaux spécifié situé dans la zone de disponibilité us-east-1 de Virginie du Nord dans AWS.

En un mot, le Pile de locataires Service Cloud Voice est déployé avant toute autre pile. En effet, les autorisations et les rôles doivent être attachés aux autres ressources du centre de contact une fois qu’ils sont déployés.

Si vous avez un compte AWS, vous affichez ces ressources déployées dans la section Services IAM et S3.

Il s’agit de la première étape de l’activation initiale de notre instance Service Cloud Voice via Salesforce. Ce graphique peut simplifier l’ordre dans lequel notre plateforme est déployée.

Ce graphique ne représente qu’une partie de la manière dont notre application Service Cloud Voice est construite et dont les autorisations sont partagées entre les services de l’application. Mais cet article consiste essentiellement à apprendre comment ces services peuvent se connecter et partager des informations, ce qui pourrait être la partie la plus significative de l’utilisation de Service Cloud Voice en tant que centre de contact/solution CRM.

Service Cloud Voice est la plate-forme de « guichet unique » pour toute entreprise cherchant à mettre en œuvre une application Web de centre de contact complète et rentable, capable de stocker de grandes quantités de données, de transcrire et d’enregistrer les informations sur les appels, de suivre les métriques pour une meilleure compréhension de les problèmes des clients, et bien plus encore !