La fusion de cas Salesforce regroupe jusqu'à trois cases en double dans un seul case maître, et la fusion ne peut pas être annulée. Les admins l'activent dans Setup, choisissent si les doublons sont conservés avec un statut Merged ou supprimés, et ajoutent l'action Merge Cases ainsi que le bouton de liste. Les listes associées, les éléments du fil et les enregistrements enfants passent au maître. Les milestones, Case Share et Case Team non, et les pièces jointes peuvent être perdues. La prévention compte plus que le nettoyage : la plupart des doublons viennent du threading des e-mails. Un coéquipier IA comme eesel peut repérer l'original probable et laisser une note, pour qu'un agent fusionne avec le contexte déjà sous les yeux.
Je travaille sur la file de support d'eesel, donc les doublons sont pour moi une nuisance quotidienne plutôt qu'un sujet abstrait de qualité des données. Chaque deuxième case sur le même problème divise l'historique d'un client entre deux enregistrements et envoie deux personnes répondre à une seule question. Pour ce guide, j'ai lu de bout en bout la documentation de Salesforce sur la fusion et le threading des e-mails. Avec le eesel CLI, un agent de code peut charger la politique de fusion et de gestion des doublons approuvée comme connaissance, puis poser des questions test pour vérifier les réponses avant toute mise en production. Connecter l'org Salesforce elle-même nécessite toujours quelqu'un avec des droits admin pour l'approuver.
Que fait vraiment la fusion de cas Salesforce ?
Elle regroupe jusqu'à trois cases en un seul, en conservant celui que vous choisissez comme maître. L'article sur la fusion de Salesforce dit que vous comparez les valeurs de champs, sélectionnez celles que vous voulez pour le maître, et que « toutes les listes associées, les éléments du fil et les enregistrements enfants sont ajoutés au maître ».
Ce qui arrive aux autres cases est une décision d'admin. Si l'org est réglée pour supprimer les doublons, ils sont supprimés de façon réversible et restent 15 jours dans la corbeille. Si elle les conserve, le mot « Merged » est ajouté au sujet dans le Highlights panel, et un lien sur le doublon vous mène au case principal.
Salesforce classe toujours cela sous Service Cloud, mais le nom de produit plus récent est Agentforce Service. L'objet Case et la fonctionnalité de fusion sont les mêmes, donc cherchez les deux noms quand vous traquez la documentation. Si vous découvrez l'objet lui-même, mon guide sur le système de tickets Salesforce couvre comment les cases arrivent et se déplacent.
Comment fusionner des cases en double étape par étape ?
Il existe trois points d'entrée, et tous limitent la sélection à trois cases. Salesforce documente chacun sur la même page de fusion :
- Depuis la vue liste Cases. Sélectionnez jusqu'à trois cases, cliquez sur Merge Cases, choisissez le maître dans la fenêtre Compare Cases, sélectionnez les valeurs de champs, puis cliquez sur Next et Merge.
- Depuis la fiche d'un Case. Ouvrez le case, utilisez le menu du Highlights panel, cliquez sur Merge Cases et recherchez les cases à fusionner. C'est la méthode à utiliser quand le doublon n'est pas dans votre vue liste actuelle.
- Depuis une liste associée sur n'importe quel objet standard. Ouvrez un compte, choisissez View All sur le panneau Cases, sélectionnez jusqu'à trois cases et cliquez sur Merge Cases.
Les agents ont besoin de Read, Create, Edit et Delete sur les cases, selon le tableau des permissions de cette page. Si le bouton manque, le premier suspect est la configuration admin ci-dessous, pas le profil de l'agent.
Comment configurer la fusion de cas dans Lightning ?
Activez le réglage, décidez ce qui arrive aux doublons, puis placez l'action là où les agents peuvent la trouver. L'article de configuration de Salesforce dit qu'il vous faut à la fois Manage Cases et Customize Application, puis :
- Dans Setup, saisissez
Case Mergedans Quick Find et sélectionnez Case Merge. - Activez Merge Cases pour accéder aux réglages.
- Choisissez Delete duplicate cases after merge, ou conservez-les et attribuez un statut depuis la liste Merged Case Status (ou ajoutez-en un propre avec Add a Case Status).
- Ajoutez l'action Merge Cases à la page de la fiche case et le bouton Merge Cases à la vue liste.
- Vous pouvez aussi ajouter une liste associée Merged Cases à la mise en page du case, depuis Object Manager comme toute autre liste associée.
Sur cette capture, l'option Keep est annotée comme recommandée. Je suis d'accord : conservez les doublons avec un statut Merged jusqu'à ce que vous ayez confiance en votre processus. Les doublons supprimés quittent la corbeille après 15 jours, et puisqu'une fusion ne peut pas être annulée, un doublon conservé est la seule piste d'audit dont vous disposerez si un agent a choisi le mauvais maître.
Qu'est-ce qui se perd ou reste de côté lors d'une fusion ?
Pas mal de choses sont documentées, et certaines sont faciles à manquer. L'article de configuration liste ces limitations :
| Limitation | Ce que cela signifie pour vous |
|---|---|
| Impossible d'annuler une fusion | Vérifiez le maître et les choix de champs sur l'écran de comparaison avant de cliquer sur Merge |
| Case Milestones, Case Share et Case Team ne sont pas fusionnés | Le maître conserve seulement sa propre horloge SLA et son équipe |
| Les pièces jointes ne sont pas prises en charge et peuvent être supprimées | Sauvegardez d'abord tout fichier dont vous avez besoin depuis le doublon |
| La fenêtre Compare Cases n'affiche que les 35 premiers champs lookup de la mise en page | Un lookup au-delà de ça ne peut pas être choisi au moment de la fusion |
| Les Actions et Recommendations sur le case principal sont dupliquées | Attendez-vous à des suggestions doublées après une fusion |
| Les cases en attente dans une file Omni-Channel, ou assignés avec un statut Opened ou Assigned, ne peuvent pas être fusionnés | Voir la section Omni-Channel ci-dessous |
Deux de ces points changent la façon dont je choisirais un maître. Comme les milestones ne se déplacent pas, choisissez le case dont l'entitlement et l'horloge SLA sont les vrais, en général le plus ancien. Mon guide sur les entitlements et milestones explique pourquoi un case sans entitlement n'obtient aucune horloge. Et comme les pièces jointes sont à risque, traitez la fusion comme le moment de déplacer les fichiers à la main. Un case fusionné peut finir avec un fil très long, donc les résumés de cases par IA aident le prochain agent à rattraper vite.
Un détail des e-mails compte aussi. Les considérations de threading de Salesforce disent qu'après la fusion de deux cases, tous les e-mails entrants suivants se rattachent au case parent, même s'ils concernaient l'enfant, et que l'agent qui fusionne décide quel case est le parent.
Peut-on fusionner un case en attente dans une file Omni-Channel ?
Par défaut non, et un réglage bêta change cela pour les cases non ouverts. La limitation par défaut bloque les doublons en attente dans une file Omni-Channel ou assignés à des agents avec un statut Opened ou Assigned. L'article bêta de Salesforce ajoute une case à cocher dans la configuration Case Merge qui autorise les cases Pending Routing et Assigned, et continue de bloquer les Opened.
Ce doublon peut-il être fusionné ?
Choisissez le réglage bêta et où se trouve le doublon dans Omni-Channel. La réponse suit les règles documentées de Salesforce.
La raison de cette limite est le cycle de vie du routage. Une fois qu'un agent accepte un élément de travail, le case est en cours, et une fusion faite par quelqu'un d'autre pourrait écraser la session de cet agent. L'erreur indique « We couldn't merge these cases. One or more of the duplicate cases is currently being worked on », et la solution est que l'agent ferme l'onglet ou libère l'élément de travail. Salesforce qualifie la fonctionnalité de bêta sous ses Beta Services Terms, donc je la testerais d'abord dans un sandbox. Mon guide de routage Omni-Channel couvre les enregistrements de routage en attente et d'assignation derrière ces états.
D'où viennent les cases en double ?
Surtout des e-mails qui ne correspondent à aucun case existant. La page de threading Email-to-Case de Salesforce explique l'ordre de correspondance. Sous le threading Lightning, un e-mail entrant est d'abord comparé via un jeton de 23 caractères dans le sujet ou le corps. Si ça échoue, Salesforce vérifie les en-têtes In-Reply-To, References et Thread-Index. Si les deux échouent, il crée un nouveau case.
La page des limitations nomme les façons dont la correspondance échoue :
- Un client modifie le sujet. Selon le client de messagerie, changer le sujet peut supprimer le jeton de threading et causer un nouveau case.
- Plus d'une adresse de routage. Salesforce dit de demander aux clients d'écrire à une seule adresse, et indique qu'envoyer à plusieurs cause des résultats inattendus et n'est pas pris en charge.
- Relais et serveurs de messagerie qui modifient les en-têtes. Un relais qui change le Message-ID de Salesforce doit déplacer l'original dans l'en-tête References, et un agent de transfert de courrier personnalisé qui supprime References ou In-Reply-To peut causer de nouveaux cases.
- Ancien threading par Ref ID. Sans threading Lightning ou basé sur les en-têtes, une réponse sans son Ref ID crée un nouveau case. Salesforce qualifie le threading par Ref ID de maintenance uniquement et recommande de basculer.
- Un sandbox actualisé. Si l'ID de l'org change, le jeton lié à l'ancien ID d'org cesse de fonctionner.
Le threading couvre les e-mails. Pour les formulaires web et les canaux de messagerie, je n'ai pas trouvé de mécanisme de correspondance comparable dans la documentation Salesforce que j'ai lue, donc je supposerais qu'un client qui soumet deux fois, ou démarre une seconde session, peut finir avec un second case. Vérifiez cela sur votre propre org avant de vous y fier. Si les doublons viennent de plusieurs personnes surveillant une même boîte, le ticket swarming est un problème lié. Pour savoir où atterrissent ces canaux, consultez mon guide sur Enhanced Messaging.
Salesforce peut-il suggérer des doublons avant que les agents les trouvent ?
Oui, dans une bêta appelée Enhanced Case Merge. L'article sur Enhanced Case Merge de Salesforce décrit le passage « d'un nettoyage manuel et réactif à une prévention proactive » en trois étapes :
- Dans la configuration Case Merge, cochez Merge cases with Enhanced Case Merge.
- Sous Duplicate Rules, donnez un nom à chaque règle, choisissez une matching rule qui décide comment les doublons sont identifiés, et définissez les conditions qu'un case doit remplir avant que la règle s'exécute.
- Faites glisser le composant Duplicate Cases sur la page de la fiche case dans Lightning App Builder.
Le composant liste ensuite les doublons probables avec numéro de case, sujet, contact et date d'ouverture, plus un bouton qui ouvre la fenêtre de fusion avec le case actuel préselectionné comme principal. C'est une bêta, donc le même conseil de test en sandbox s'applique. Elle laisse aussi la fusion entre les mains d'une personne, ce qui est exactement où je la garderais.
Comment l'IA peut-elle réduire les cases en double ?
En répondant plus vite et en pointant vers l'original, pas en fusionnant de son propre chef. Une fusion ne peut pas être annulée, donc je ne laisserais jamais un agent IA en faire une sans supervision. Ce qu'un agent peut faire en toute sécurité, c'est lire le nouveau case, chercher dans vos autres cases, et laisser une note privée du type « ceci ressemble au case ouvert ce matin par le même contact ». L'intégration eesel avec Salesforce fonctionne ainsi à l'intérieur de l'org : elle lit les cases et les articles Knowledge, rédige des réponses comme commentaires internes du case, et peut d'abord consulter le compte et chercher dans les autres cases, selon sa documentation. Votre agent ne voit que ce que l'utilisateur Salesforce autorisé peut voir, donc les permissions d'objet et de champ restent la vraie limite.
Cette limite s'accorde avec toute revue de gouvernance IA que vous menez déjà. Les propres limitations IA de Salesforce méritent d'être lues avant de choisir une couche.
Deux histoires clients montrent le même schéma sur d'autres helpdesks. Rúngne fait tourner trois agents sur Gorgias, où e-mail, chat et commentaires sociaux partagent une seule file. En un mois, ses agents ont traité environ 2 100 tickets, en ont tagué environ 880, ont laissé environ 580 réponses brouillon comme notes internes, et ont répondu directement à environ un ticket sur sept. Le bruit, comme les commentaires publicitaires, les réponses d'absence et le spam, est tagué puis fermé, si bien qu'il ne devient jamais un second enregistrement à nettoyer, une tâche plus proche de la classification de tickets que de la fusion. Chez SamCart, un agent Freshdesk envoie la première réponse seulement quand aucun coéquipier n'est encore assigné. Ma lecture est qu'une première réponse rapide réduit les relances du type « des nouvelles ? » qui deviennent si souvent des doublons, même si aucune des deux histoires ne mesure les doublons directement.
Pour des réponses plus rapides, voyez mon guide sur l'automatisation de la première réponse. Pour moins de tickets en général, voyez la déviation de tickets.
Pour la même idée sur d'autres plateformes, voyez mon guide sur la déduplication de tickets. La version Freshdesk de cette tâche se trouve dans la fusion de tickets Freshdesk.
Si votre file est déjà bruyante avant d'être dupliquée, commencez par le filtrage du spam. Ma comparaison des boîtes partagées couvre le côté admission.
Que mettrais-je en place en premier ?
Prévenir d'abord, puis rendre le nettoyage sûr. Voici l'ordre que j'utiliserais sur une org Service Cloud :
- Vérifiez votre méthode de threading. Si Setup affiche des réglages « Insert thread ID », vous êtes sur le threading par Ref ID. Passez au threading Lightning, et activez à la fois l'option jeton et l'option en-têtes.
- Réduisez les adresses de routage. Une adresse par boîte visible des clients, et dites aux clients de ne pas en mettre plusieurs en copie.
- Activez Case Merge avec Keep sélectionné. Ajoutez un statut Merged clair, l'action, le bouton de liste et la liste associée Merged Cases.
- Écrivez une règle de case maître. La mienne est : le case le plus ancien avec un entitlement valide, et déplacer les pièces jointes à la main d'abord.
- Formez les agents à la règle Omni-Channel. Les cases au statut Opened ne peuvent pas être fusionnés, donc libérez l'élément de travail avant une fusion.
- Testez Enhanced Case Merge dans un sandbox. Commencez avec une seule règle de doublons bien ciblée.
- Ajoutez une couche de notes IA. Laissez un agent signaler les originaux probables, et gardez le clic de fusion entre les mains d'un agent humain. Transmettez les cas vraiment délicats avec l'escalade IA.
Si ce qui vous préoccupe, c'est ce que coûte Service Cloud une fois ces add-ons accumulés, mon détail des tarifs couvre les éditions. Pour voir ce que vous pouvez automatiser d'autre sur l'objet Case, voyez l'automatisation des cases Salesforce. Pour la vue plus large, commencez par l'IA pour helpdesk.
Essayer eesel pour Salesforce Service Cloud
Si les cases en double dévorent le temps de vos agents, eesel fonctionne comme une nouvelle recrue qui se branche sur votre org Service Cloud, lit chaque nouveau case avec l'historique du compte, et laisse un brouillon ou une note « possible duplicate of » comme commentaire interne. Vos agents gardent la décision de fusion, et votre admin garde le contrôle de ce que l'agent peut voir. Gratuit à essayer.
Comment fusionner des cases dans Salesforce ?