La fusión de casos de Salesforce combina hasta tres casos duplicados en un caso maestro, y la fusión no se puede deshacer. Los administradores la activan en Setup, eligen si los duplicados se mantienen con estado Merged o se eliminan, y añaden la acción Merge Cases y el botón de lista. Las listas relacionadas, los elementos del feed y los registros secundarios pasan al maestro. Los milestones, Case Share y Case Team no, y los adjuntos pueden perderse. La prevención importa más que la limpieza: la mayoría de los duplicados se originan en el threading de correo. Un compañero de IA como eesel puede detectar el posible original y dejar una nota, para que un agente fusione con el contexto que ya tiene delante.
Trabajo en la cola de soporte de eesel, así que los duplicados son para mí una molestia diaria y no un tema abstracto de calidad de datos. Cada segundo caso sobre el mismo problema divide el historial de un cliente en dos registros y hace que dos personas respondan a una sola pregunta. Para esta guía leí de principio a fin la documentación de Salesforce sobre fusión y threading de correo. Con el eesel CLI, un agente de código puede subir la política aprobada de fusión y manejo de duplicados como conocimiento, y luego hacer preguntas de prueba para revisar las respuestas antes de que algo salga en producción. Conectar la propia org de Salesforce sigue necesitando que alguien con permisos de administrador lo apruebe.
¿Qué hace realmente la fusión de casos de Salesforce?
Combina hasta tres casos en uno, y conserva el que elijas como maestro. El artículo de fusión de Salesforce dice que comparas los valores de campo, eliges los que quieres para el maestro, y que «todas las listas relacionadas, los elementos del feed y los registros secundarios se añaden al maestro».
Qué pasa con los otros casos es una decisión del administrador. Si la org está configurada para eliminar duplicados, se eliminan de forma reversible y quedan 15 días en la papelera de reciclaje. Si los conserva, se añade la palabra «Merged» al asunto en el Highlights panel, y un enlace en el duplicado te lleva al caso principal.
Salesforce sigue clasificando esto bajo Service Cloud, pero el nombre de producto más nuevo es Agentforce Service. El objeto Case y la función de fusión son los mismos, así que busca ambos nombres cuando rastrees documentación. Si eres nuevo con el objeto en sí, mi guía de sistema de tickets de Salesforce cubre cómo llegan y se mueven los casos.
¿Cómo se fusionan casos duplicados paso a paso?
Hay tres puntos de entrada, y todos limitan la selección a tres casos. Salesforce documenta cada uno en la misma página de fusión:
- Desde la vista de lista de Cases. Selecciona hasta tres casos, haz clic en Merge Cases, elige el maestro en la ventana Compare Cases, selecciona los valores de campo y luego haz clic en Next y Merge.
- Desde la página de un registro de Case. Abre el caso, usa el menú del Highlights panel, haz clic en Merge Cases y busca los casos que quieres fusionar. Es la opción cuando el duplicado no está en tu vista de lista actual.
- Desde una lista relacionada en cualquier objeto estándar. Abre una cuenta, elige View All en el panel de Cases, selecciona hasta tres casos y haz clic en Merge Cases.
Los agentes necesitan Read, Create, Edit y Delete sobre casos, según la tabla de permisos de esa página. Si falta el botón, el primer sospechoso es la configuración de administrador de abajo, no el perfil del agente.
¿Cómo se configura la fusión de casos en Lightning?
Activa el ajuste, decide qué pasa con los duplicados, y pon la acción donde los agentes puedan encontrarla. El artículo de configuración de Salesforce dice que necesitas tanto Manage Cases como Customize Application, y luego:
- En Setup, escribe
Case Mergeen Quick Find y selecciona Case Merge. - Activa Merge Cases para llegar a los ajustes.
- Elige Delete duplicate cases after merge, o conserva los duplicados y asigna un estado desde la lista Merged Case Status (o añade uno propio con Add a Case Status).
- Añade la acción Merge Cases a la página del registro de caso y el botón Merge Cases a la vista de lista.
- Opcionalmente, añade una lista relacionada Merged Cases al layout del caso, desde Object Manager como cualquier otra lista relacionada.
En esa captura, la opción Keep aparece etiquetada como recomendada. Estoy de acuerdo: conserva los duplicados con estado Merged hasta que confíes en tu proceso. Los duplicados eliminados salen de la papelera después de 15 días, y como una fusión no se puede deshacer, un duplicado conservado es la única pista de auditoría que tendrás si un agente eligió el maestro equivocado.
¿Qué se pierde o queda atrás en una fusión?
Bastante está documentado, y parte es fácil de pasar por alto. El artículo de configuración enumera estas limitaciones:
| Limitación | Qué significa para ti |
|---|---|
| No se puede deshacer una fusión | Revisa el maestro y las elecciones de campo en la pantalla de comparación antes de hacer clic en Merge |
| Case Milestones, Case Share y Case Team no se fusionan | El maestro conserva solo su propio reloj de SLA y su propio equipo |
| Los adjuntos no son compatibles y pueden eliminarse | Guarda primero cualquier archivo que necesites del duplicado |
| La ventana Compare Cases muestra solo los primeros 35 campos de búsqueda del layout | Un campo de búsqueda más allá de eso no se puede elegir al fusionar |
| Las Actions y Recommendations del caso principal se duplican | Espera sugerencias duplicadas después de una fusión |
| Los casos pendientes en una cola de Omni-Channel, o asignados con estado Opened o Assigned, no se pueden fusionar | Ver la sección de Omni-Channel más abajo |
Dos de estas cambian cómo elegiría yo un maestro. Como los milestones no se mueven, elige el caso cuyo entitlement y reloj de SLA sean los reales, que suele ser el más antiguo. Mi guía de entitlements y milestones explica por qué un caso sin entitlement no obtiene ningún reloj. Y como los adjuntos están en riesgo, trata la fusión como el momento de mover archivos a mano. Un caso fusionado puede terminar con un feed largo, así que los resúmenes de casos con IA ayudan al siguiente agente a ponerse al día rápido.
Un detalle de correo también importa. Las consideraciones de threading de Salesforce dicen que, tras fusionar dos casos, todos los correos entrantes posteriores se adjuntan al caso padre, incluso si eran sobre el hijo, y que el agente que fusiona decide cuál caso es el padre.
¿Se puede fusionar un caso que está esperando en una cola de Omni-Channel?
Por defecto no, y un ajuste beta cambia eso para los casos no abiertos. La limitación por defecto bloquea los duplicados que están pendientes en una cola de Omni-Channel o asignados a agentes con estado Opened o Assigned. El artículo beta de Salesforce añade una casilla en la configuración de Case Merge que permite casos con Pending Routing y Assigned, y sigue bloqueando los Opened.
¿Se puede fusionar este duplicado?
Elige el ajuste beta y dónde está el duplicado en Omni-Channel. La respuesta sigue las reglas documentadas de Salesforce.
El motivo de esta línea es el ciclo de vida del ruteo. Una vez que un agente acepta un elemento de trabajo, el caso está en curso, y una fusión hecha por otra persona podría sobrescribir la sesión de ese agente. El error dice «We couldn't merge these cases. One or more of the duplicate cases is currently being worked on», y la solución es que el agente cierre la pestaña o libere el elemento de trabajo. Salesforce etiqueta la función como beta bajo sus Beta Services Terms, así que yo la probaría primero en un sandbox. Mi guía de enrutamiento de Omni-Channel cubre los registros de ruteo pendiente y asignación detrás de esos estados.
¿De dónde vienen los casos duplicados?
La mayoría vienen de correos que no coinciden con un caso existente. La página de threading de Email-to-Case de Salesforce explica el orden de coincidencia. Bajo el threading de Lightning, un correo entrante se compara primero con un token de 23 caracteres en el asunto o el cuerpo. Si eso falla, Salesforce revisa los encabezados In-Reply-To, References y Thread-Index. Si ambos fallan, crea un caso nuevo.
La página de limitaciones nombra las formas en que falla la coincidencia:
- Un cliente edita el asunto. Según el cliente de correo, cambiar el asunto puede eliminar el token de threading y causar un caso nuevo.
- Más de una dirección de enrutamiento. Salesforce dice que pidas a los clientes que escriban a una sola dirección, y que enviar a varias causa resultados inesperados y no está soportado.
- Relés y servidores de correo que modifican encabezados. Un relé que cambia el Message-ID de Salesforce debe mover el original al encabezado References, y un agente de transferencia de correo personalizado que elimina References o In-Reply-To puede causar casos nuevos.
- Threading antiguo por Ref ID. Sin threading de Lightning o basado en encabezados, una respuesta sin su Ref ID crea un caso nuevo. Salesforce califica el threading por Ref ID como solo de mantenimiento y recomienda cambiar.
- Un sandbox actualizado. Si cambia el ID de la org, el token vinculado al ID de la org antigua deja de funcionar.
El threading cubre el correo. Para formularios web y canales de mensajería no encontré un mecanismo de coincidencia comparable en la documentación de Salesforce que leí, así que asumiría que un cliente que envía dos veces, o inicia una segunda sesión, puede terminar con un segundo caso. Compruébalo en tu propia org antes de confiar en ello. Si los duplicados vienen de varias personas vigilando una misma bandeja, el enjambre de tickets es un problema relacionado. Para saber dónde aterrizan esos canales, consulta mi guía de Enhanced Messaging.
¿Puede Salesforce sugerir duplicados antes de que los agentes los encuentren?
Sí, en una beta llamada Enhanced Case Merge. El artículo de Enhanced Case Merge de Salesforce describe el paso «de la limpieza manual y reactiva a la prevención proactiva» en tres pasos:
- En la configuración de Case Merge, marca Merge cases with Enhanced Case Merge.
- En Duplicate Rules, da un nombre a cada regla, elige una matching rule que decida cómo se identifican los duplicados, y define las condiciones que debe cumplir un caso antes de que la regla se ejecute.
- Arrastra el componente Duplicate Cases a la página del registro de caso en Lightning App Builder.
El componente entonces lista duplicados probables con número de caso, asunto, contacto y fecha de apertura, más un botón que abre la ventana de fusión con el caso actual preseleccionado como principal. Es una beta, así que aplica el mismo consejo de probar primero en un sandbox. Además, sigue dejando la fusión en manos de una persona, que es donde yo la mantendría.
¿Cómo puede la IA reducir los casos duplicados?
Respondiendo antes y señalando el original, no fusionando por su cuenta. Una fusión no se puede deshacer, así que nunca dejaría que un agente de IA hiciera una sin supervisión. Lo que un agente puede hacer de forma segura es leer el caso nuevo, buscar en tus otros casos, y dejar una nota privada como «esto parece el caso abierto esta mañana por el mismo contacto». La integración de eesel con Salesforce funciona así dentro de la org: lee casos y artículos de Knowledge, redacta respuestas como comentarios internos del caso, y puede buscar primero la cuenta y otros casos, según su documentación. Tu agente solo ve lo que puede ver el usuario de Salesforce autorizado, así que los permisos de objeto y campo siguen siendo el límite real.
Ese límite encaja con cualquier revisión de gobernanza de IA que ya hagas. Las propias limitaciones de IA de Salesforce merecen lectura antes de elegir una capa.
Dos historias de clientes muestran el mismo patrón en otros helpdesks. Rúngne opera tres agentes en Gorgias, donde correo, chat y comentarios sociales comparten una sola cola. En un mes, sus agentes gestionaron unos 2.100 tickets, etiquetaron unos 880, dejaron unas 580 respuestas de borrador como notas internas, y respondieron directamente a cerca de uno de cada siete tickets. El ruido, como comentarios publicitarios, respuestas de ausencia y spam, se etiqueta y se cierra, de modo que nunca se convierte en un segundo registro que limpiar, una tarea más cercana a la clasificación de tickets que a la fusión. En SamCart, un agente de Freshdesk envía la primera respuesta solo cuando aún no hay compañero asignado. Mi lectura es que una primera respuesta rápida reduce los seguimientos de «¿alguna novedad?» que tan a menudo se convierten en duplicados, aunque ninguna de las dos historias mide los duplicados directamente.
Para respuestas más rápidas, consulta mi guía de automatización de primera respuesta. Para menos tickets en general, consulta desvío de tickets.
Para la misma idea en otras plataformas, consulta mi guía de deduplicación de tickets. La versión de Freshdesk de esta tarea está en fusión de tickets de Freshdesk.
Si tu cola ya es ruidosa antes de duplicarse, empieza con filtrado de spam. Mi comparación de bandeja compartida cubre el lado de la entrada.
¿Qué configuraría yo primero?
Prevenir primero, y luego hacer segura la limpieza. Este es el orden que usaría en una org de Service Cloud:
- Revisa tu método de threading. Si Setup muestra ajustes de «Insert thread ID», estás en threading por Ref ID. Pasa al threading de Lightning, y activa tanto la opción de token como la de encabezados.
- Reduce las direcciones de enrutamiento. Una dirección por bandeja de cara al cliente, y dile a los clientes que no copien a varias.
- Activa Case Merge con Keep seleccionado. Añade un estado Merged claro, la acción, el botón de lista y la lista relacionada Merged Cases.
- Escribe una regla de caso maestro. La mía es: el caso más antiguo con un entitlement válido, y mover los adjuntos a mano primero.
- Entrena a los agentes en la regla de Omni-Channel. Los casos con estado Opened no se pueden fusionar, así que libera el elemento de trabajo antes de fusionar.
- Prueba Enhanced Case Merge en un sandbox. Empieza con una sola regla de duplicados bien acotada.
- Añade una capa de notas con IA. Deja que un agente marque los originales probables, y mantén el clic de fusión en manos de un agente humano. Pasa los casos realmente difíciles con escalamiento con IA.
Si te preocupa lo que cuesta Service Cloud cuando se acumulan estos add-ons, mi desglose de precios cubre las ediciones. Para ver qué más puedes automatizar en el objeto Case, mira automatización de casos de Salesforce. Para la visión más amplia, empieza con IA para helpdesk.
Prueba eesel para Salesforce Service Cloud
Si los casos duplicados están consumiendo el tiempo de tus agentes, eesel funciona como una nueva incorporación que se conecta a tu org de Service Cloud, lee cada caso nuevo junto con el historial de la cuenta, y deja un borrador o una nota de «possible duplicate of» como comentario interno. Tus agentes conservan la decisión de fusión, y tu administrador conserva el control de lo que el agente puede ver. Gratis para probar.
