Vue d'ensemble
Cette proposition couvre l'évolution du scénario Make existant « Kenzi : Typeform Résiliations » pour ajouter, après l'envoi du mail Outlook au client, une consignation automatique de la communication dans Salesforce.
L'objectif : que chaque demande de résiliation reçue via Typeform laisse une trace propre, recherchable et reliée au bon compte / contact côté CRM, sans intervention manuelle, et sans créer d'orphelin si le client n'est pas trouvé.
Le scénario reste unique et continu dans Make : Typeform → Outlook → Salesforce. Aucun nouvel outil, aucune refonte du flux actuel. La logique CRM est greffée après l'envoi du mail, donc même en cas d'erreur Salesforce, le client reçoit toujours sa confirmation.
Contexte et besoin
Aujourd'hui, lorsqu'un client soumet le formulaire Typeform de résiliation, le scénario Make « Kenzi : Typeform Résiliations » envoie un mail Outlook de confirmation au client, avec en copie direction@ et facturation@.
Le mail part bien, mais aucune trace n'est conservée dans Salesforce. Résultat : les commerciaux et la direction n'ont aucune visibilité CRM sur les demandes de résiliation entrantes, et il faut aller fouiller dans Outlook pour reconstruire l'historique d'un client.
Tu as déjà tenté de le faire toi-même, mais le matching compte / contact et le bon objet Salesforce à utiliser bloquent. C'est précisément ce qu'on cadre et qu'on livre dans cette évolution.
Choix techniques retenus
Tu as proposé trois arbitrages dans ta demande. Voici, pour chacun, le choix recommandé et son justificatif technique.
Choix 1 Forme de l'activité Salesforce
Recommandation : EmailMessage (objet natif Salesforce dédié aux échanges email).
Pourquoi : EmailMessage est l'objet officiel pour stocker une communication email. Il apparaît dans le timeline d'activité de la fiche, conserve le From / To / Cc, le HtmlBody et le TextBody, et se relie proprement au Contact (RelatedToId → Account, ToAddress → client). C'est la solution la plus propre pour un audit trail.
Fallback Si le profil Salesforce ne dispose pas des permissions Create EmailMessage, on bascule automatiquement sur une Task de type « Email » (Subject, Description, Type=Email, Status=Completed), même rendu visuel dans Activités, sans dépendance de permissions.
Choix 2 Matching compte / contact
Recommandation : ta logique en cascade, validée et étendue.
- 1.Search Contact par email (email Typeform) → on récupère
IdetAccountId. - 2.Fallback : Search Account par nom de société (champ Typeform) → on récupère
AccountId, sans WhoId. - !Aucun match : envoi d'une notification interne (Slack canal interne ou email à toi) avec le payload Typeform complet, et pas de création d'orphelin Salesforce.
Détail La notif d'erreur contient : email saisi, société saisie, lien direct vers la soumission Typeform, et le motif (contact introuvable / société introuvable). Tu peux donc traiter à la main en 30 secondes.
Choix 3 Champs renseignés sur l'activité
| Champ Salesforce | Valeur |
|---|---|
| Subject | « Demande de résiliation reçue : [nom société] » |
| Description / HtmlBody | Corps complet du mail envoyé au client (HTML conservé) |
| Date d'activité | Date / heure d'envoi du mail Outlook |
| Type | |
| Status | Completed |
| WhoId | Contact trouvé (si match Contact) |
| WhatId / RelatedToId | Account (toujours rempli si on a un match) |
| ToAddress / CcAddress | Email client / direction@ + facturation@ (en mode EmailMessage) |
Workflow proposé (après l'envoi mail)
Étapes ajoutées dans le scénario Make existant, branchées après le module Outlook :
Salesforce : Search Records (Contact)
Recherche par Email = {{ email Typeform }}. Limite : 1. Récupère Id et AccountId.
Router : Contact trouvé ? Oui / Non
Si oui → étape 4. Si non → étape 3 (fallback Account).
Salesforce : Search Records (Account)
Recherche par Name = {{ société Typeform }} (avec normalisation : trim, casse, accents). Si aucun résultat → étape 6 (notif).
Salesforce : Create EmailMessage
Crée l'enregistrement avec tous les champs (cf. choix 3). RelatedToId = AccountId. Ajout du Contact en EmailMessageRelation si trouvé.
Fallback automatique : Task
En cas d'erreur de permission sur EmailMessage, le module bascule sur la création d'une Task type Email, Status Completed, avec les mêmes liens WhoId / WhatId.
Notification interne : Aucun match
Envoi Slack ou email à toi, avec le payload Typeform complet et le lien vers la soumission. Aucune création d'orphelin Salesforce.
Robustesse : chaque étape Salesforce est en mode error handler. Si Salesforce répond une erreur (timeout, schema, perms), le scénario log et notifie, il ne casse pas le flux, et le mail au client a déjà été envoyé.
Périmètre
Inclus
- ✓Audit du scénario Make existant et du mapping de champs Typeform.
- ✓Branchement de la connexion Salesforce dans Make (OAuth, vérification des permissions sur EmailMessage et Task).
- ✓Implémentation des 6 étapes du workflow ci-dessus.
- ✓Logique de matching Contact → Account → notif (sans création d'orphelin).
- ✓Tests bout-en-bout : 3 scénarios (contact existant, account seul, aucun match).
- ✓Documentation courte du scénario (1 page) avec capture d'écran et logique de chaque module.
- ✓1 semaine de support post-livraison : tout bug ou ajustement mineur corrigé sans surcoût.
Non inclus
- ✗Refonte du scénario actuel ou modification du mail Outlook envoyé au client.
- ✗Changements de schéma Salesforce (création de champs custom, validation rules, layouts).
- ✗Migration des historiques d'anciennes résiliations vers Salesforce.
- ✗Mise en place ou paiement d'opérations Make supplémentaires (le scénario tourne déjà dans ton compte).
Livrables
- •Scénario Make « Kenzi : Typeform Résiliations » mis à jour, en place et activé sur ton compte.
- •Connexion Salesforce configurée dans Make (OAuth dédié, scope minimal).
- •3 jeux de tests joués ensemble, captures Salesforce à l'appui (EmailMessage créé, Account lié, Contact relié).
- •Mini-documentation (1 page) : schéma du flux, mapping des champs, mode d'emploi du fallback.
- •Canal Slack ou email de notification d'erreur, paramétrable côté toi.
Planning
| # | Phase | Durée |
|---|---|---|
| 1 | Cadrage rapide : accès Make + Salesforce, validation EmailMessage vs Task selon tes permissions | J0, 30 min |
| 2 | Construction : ajout des modules dans Make, mapping des champs, error handlers | J+1 |
| 3 | Tests bout-en-bout : 3 cas (match Contact / match Account / no match) avec preuves Salesforce | J+2 |
| 4 | Mise en production + doc : activation, remise de la doc, walkthrough rapide en visio | J+2 |
| 5 | Support post-livraison : correction de tout bug remonté, sans surcoût | J+3 → J+10 |
Délai indicatif : livraison sous 3 jours ouvrés à compter de la réception des accès Make et Salesforce.
Garanties
Garantie fonctionnelle
L'évolution livrée passe les 3 cas de test. Sinon, on corrige sans surcoût.
Support 7 jours
1 semaine de maintenance post-livraison incluse. Bug = correction gratuite.
Documentation
Une page claire pour que tu (ou Kenzi) puissiez maintenir le flux en autonomie.
Propriété complète
Le scénario, les connexions et la doc t'appartiennent dès la livraison.
Tarif
Forfait fixe. Aucun coût récurrent côté Auryon (les opérations Make consommées restent sur ton compte Make).
Prochaines étapes
| # | Action | Responsable |
|---|---|---|
| 1 | Validation de cette proposition par retour mail | Rémi |
| 2 | Partage des accès Make (scénario Kenzi) et Salesforce (utilisateur dédié, perms EmailMessage) | Rémi |
| 3 | Cadrage 30 min en visio : arbitrage final EmailMessage vs Task selon ton org Salesforce | Les deux |
| 4 | Construction et tests bout-en-bout | Auryon |
| 5 | Walkthrough de livraison et activation en production | Les deux |
Prêt à tracer proprement les résiliations dans Salesforce ?
On peut démarrer cette semaine
Valider et démarrer →Un simple email suffit, on cale le call de cadrage dans la foulée.