À retenir avant de commencer
Notre connecteur communique uniquement avec les objets Marketing standards suivants de Salesforce :
Contacts
Comptes
Prospects
Membres de Campagne
Par ailleurs il ne supprimera jamais des objets de votre instance. En effet, notre connecteur a pour fonction de faire remonter les données d'inscription de vos événements, et dans ce but il ne fera que créer ou mettre à jour les entités sus-citées.
Informations principales
ID de la campagne Salesforce
Les participants vont remonter sur Salesforce en tant que membres de campagne. Il faut donc que vous indiquiez la campagne Salesforce à laquelle ils seront associés.
C'est l'identifiant de la campagne dont Eventmaker a besoin. Vous pouvez le récupérer en copiant les 18 caractères qui le composent depuis la barre d'URL de votre navigateur lorsque vous êtes sur la page de la campagne.
Puis vous pouvez le coller dans le champ dédié du formulaire.
Utilisation des comptes personnels dans Salesforce
Les comptes personnels stockent des informations sur des personnes individuelles en combinant certains champs de compte et de contact en un seul enregistrement dans Salesforce. Cochez la case ci-dessous si votre instance Salesforce utilise cette option afin que le flux de données entre les 2 plateformes s'adapte à ce cas d'usage.
Une fois cette option activée, vous pouvez spécifier un type d'enregistrement pour la création des Comptes.
Réconciliation des participants avec les données Salesforce
La réconciliation consiste à vérifier si un participant existe déjà dans votre instance Salesforce, soit en tant que Contact, soit en tant que Prospect, soit en tant que Compte personnel, dans le but de ne pas créer de doublons. Cette réconciliation se fait grâce aux clés d'unicité.
Vous avez 2 choix possibles :
Vérifier uniquement dans la table des Contacts (ou les Comptes personnels si activés)
Vérifier d'abord dans la table des Contacts (ou les Comptes personnels si activés) et à défaut vérifier dans la table des Prospects
Table pour les personnes inconnues de Salesforce
Lorsqu'un participant n'existe pas encore dans votre CRM, il sera créé comme Contact, ou Compte personnel si activé, ou comme Prospect.
Si la réconciliation des participants se fait uniquement sur la table des Contacts, le participant inconnu du CRM sera forcément créé comme Contact (ou Compte personnel si activé).
Catégories de participants à faire remonter dans Salesforce
Il n'est pas obligatoire de faire remonter tous les participants d'un événement dans Salesforce. Indiquez simplement les catégories de participants concernées via la liste déroulante.
Processus
La remontée des participants dans Salesforce passe par notre outil d'Automatisation ; 4 processus sont configurés automatiquement pour vous et vous pouvez y accéder en mode lecture uniquement.
Vous pouvez cependant les désactiver individuellement. Par exemple, si vous ne souhaitez faire remonter l'information de venue des participants, vous pouvez désactiver le processus dont le déclenchement se fait à la venue d'un participant.
Statut du membre de campagne
Le statut du membre de campagne indique l'avancement de l'invité dans sa participation à l'événement. Au départ, l'invité n'est pas inscrit, ensuite il peut être inscrit, et enfin il peut être venu. Chacun de ces 3 états doit être mappé à une valeur de Statut dans Salesforce.
Par défaut nous utilisons le champ natif Status. Mais vous pouvez tout à fait utiliser un champ personnalisé que vous aurez créé au préalable sur votre instance.
Et pour chacun des 3 états, indiquez la valeur correspondante dans Salesforce.
Attention : quand vous spécifiez des références à des champs ou des valeurs de champs Salesforce, ce sont toujours les Noms API qu'il faut saisir.
Il est également à noter que l'information comme quoi le participant n'est pas inscrit n'est envoyée à Salesforce que lorsque le participant est supprimé. En effet ce dernier ne remonte la première fois dans Salesforce que dès lors qu'il passe au statut Inscrit sur Eventmaker.
Tables de mapping entre les champs Eventmaker et Salesforce
En vue de mettre à jour les données sur Salesforce, nous devons établir quelles informations de participants il est nécessaire de faire remonter sur le CRM et à quel endroit.
Par exemple on voudra typiquement que le champ first_name d’Eventmaker aille alimenter le champ FirstName de la table des Contacts ou des Prospects. Ou bien que la country de la société alimente le champ BillingCountry de la table des Comptes.
C’est pourquoi vous devez mettre en place quatre tables de mapping (trois si vous n'utilisez pas les Prospects).
L'interface utilisateur vous propose 2 modes de saisie :
un mode classique pour les utilisateurs non techniques
un mode avancé pour les utilisateurs plus chevronnés et qui permet de saisir le mapping au format YAML
Quel que soit le mode sélectionné, pour chaque champ à mapper, vous devez indiquer 4 informations :
le Nom API du champ Salesforce que vous souhaitez alimenter (
salesforce_keydans le YAML)le type de la source d'information : il s'agit soit de la valeur d'un champ de participant, soit d'une valeur statique personnalisée (
source_typeavec la valeurguest_fieldoucustomdans le YAML)la valeur personnalisée ou bien le nom du champ de participant (
source_valuedans le YAML)le moment où le champ Salesforce sera alimenté : soit uniquement à la création de l'entité sur Salesforce, soit uniquement à sa mise à jour, soit toujours qu'il s'agisse d'une création ou d'une mise à jour (
onlydans le YAML avec l'une des valeurs parmialways,create,update) ; par défaut le champ sera toujours alimenté sur Salesforce.
Lorsque le connecteur analysera les données d’un participant, chacune des tables de mapping lui permettra de construire les corps de requêtes à l’API conformément à ce qui a été défini.
Il est tout à fait possible pour le connecteur d'alimenter des champs Salesforce personnalisés (dont le Nom API finit typiquement par __c) en plus des champs natifs.
De plus, celui-ci gère à la fois les champs Texte, les champs de Liste de valeurs, les champs Case à cocher, et les champs Date/Heure.
⚠️ Grâce au 4è paramètre, vous pouvez tout à fait définir le mapping afin de ne jamais mettre à jour une entité existante : il suffit de choisir l'option "Alimenter à la création" pour chacun des champs. Cela peut être utile si vous ne souhaitez pas que l'on mette à jour certains types d'entités pour lesquels vous préférez privilégier les données existantes du CRM plutôt que les données d'inscription.
Clés d'unicité
Avant de faire remonter des données sur Salesforce, on doit être en mesure de déterminer s'il s’agit d’une création ou d'une mise à jour d’entité.
Pour effectuer cette réconciliation, on utilise une clé d'unicité (ou clé de dédoublonnage) qui représente l'entité de manière unique dans Salesforce. Si le connecteur trouve une fiche sur Salesforce correspondant à la clé qu'il aura calculée, alors il mettra à jour cette fiche, sinon il en créera une nouvelle.
Il existe une clé d'unicité pour les Contacts et les Prospects, pour lesquels il s'agira du champ Email par défaut, ainsi que pour les Comptes, pour lesquels il s'agira du champ Name par défaut.
💡 Si vous ne souhaitez pas de réconciliation au niveau des Comptes, c'est-à-dire que vous ne voulez aucune modification de Compte associé à un Contact existant, vous pouvez laisser vide le Nom API du champ Salesforce représentant la clé d'unicité.
En revanche, cette option est seulement possible si vous avez défini que le connecteur procède uniquement à des créations de Pistes (car lors d'une création de Contact, un Compte doit nécessairement lui être associé).
Continuons avec un exemple.
Partons du principe qu'il existe dans Salesforce un Contact 1 et un Contact 2 avec pour adresses email respectives contact_1@mail.com et contact_2@mail.com. Un participant vient de s'inscrire sur Eventmaker avec l'adresse email contact_2@mail.com ; ce dernier sera donc rattaché au Contact 2 qui sera mis à jour. Maintenant un autre participant s'inscrit avec l'adresse email contact_3@mail.com : étant donné qu'aucune fiche contact n'existe sur Salesforce avec cette adresse, un nouveau contact est créé.
Cependant vous pouvez vouloir définir un dédoublonnage plus fin. Pour cela vous pouvez utiliser un Champ de fusion qui sera constitué d’un ensemble d'informations du participant mises bout à bout et normalisées. Dans ce cas, vous devez créer un nouveau champ personnalisé dans Salesforce dont la valeur proviendra d'une formule qui sera évaluée à chaque mise à jour de l'entité ; vous devez aussi activer l'unicité de la valeur de ce champ afin d’assurer l’absence de doublons dans la base CRM au delà du cadre de cette intégration.
Plusieurs choses sont à définir :
le nom API du champ de fusion personnalisé représentant la clé d'unicité
les champs composants cette clé d'unicité
le caractère séparateur des composantes (qui remplace également les caractères vides comme l'espace) (peut rester vide)
les caractères spéciaux à supprimer de la clé d'unicité
les caractères spéciaux à remplacer par une valeur dans la clé d'unicité
si oui ou non on supprime les caractères accentués (nous recommandons de toujours activer cette option)
Il est également à noter que la valeur résultante sera nécessairement en minuscules et que les espaces en début et fin de valeur composante seront retirés avant tout remplacement potentiel.
Typiquement, nous recommandons une clé d'unicité composée des Nom et Email pour les Contacts et Prospects, et composée du Nom et du Code Postal pour les Comptes.
Terminons par un exemple qui sera sans doute plus parlant.
Une participante Inès du Pré avec l'adresse email ines-du-pre@mail.com vient de s'inscrire. La clé d'unicité de Contact est composée de l'email et du nom dans cet ordre, le séparateur est le tiret (-), les accents doivent être supprimés, aucun caractère spécial n'est à supprimer, et le caractère point (.) est à remplacer par le mot dot.
Pour la réconciliation, nous allons donc chercher dans Salesforce un Contact dont la clé d'unicité est : ines-du-pre@maildotcom-du-pre.
Si un Contact est retrouvé, il sera mis à jour, sinon en fonction de la configuration, soit on cherchera un prospect à partir d'une clé d'unicité (potentiellement différente), ou bien un nouveau contact sera créé.
Voici les différentes étapes permettant d'arriver à ce résultat :
Action | Valeurs en sortie |
Suppression des espaces en début et fin de composante | du Pré ines-du-pre@mail.com |
Mise en minuscule | du pré ines-du-pre@mail.com |
Remplacement des espace par le séparateur (-) | du-pré ines-du-pre@mail.com |
Suppression de caractères (aucun) | du-pré ines-du-pre@mail.com |
Remplacement de caractères (. -> dot) | du-pré ines-du-pre@maildotcom |
Suppression des accents | du-pre ines-du-pre@maildotcom |
Concaténation des composantes avec le séparateur (-) | ines-du-pre@maildotcom-du-pre |