A fusão de casos da Salesforce junta até três casos duplicados em um único caso principal, e a fusão não pode ser desfeita. Os admins ativam isso no Setup, escolhem se os duplicados ficam com status Merged ou são excluídos, e adicionam a ação Merge Cases e o botão de lista. As listas relacionadas, os itens do feed e os registros filhos passam para o principal. Milestones, Case Share e Case Team não, e os anexos podem se perder. Prevenir importa mais do que limpar depois: a maioria dos duplicados vem do threading de e-mail. Um colega de equipe de IA como eesel pode identificar o provável original e deixar uma nota, para que um agente faça a fusão com o contexto já à vista.
Trabalho na fila de suporte da eesel, então duplicados são para mim um incômodo diário, não um tema abstrato de qualidade de dados. Cada segundo caso sobre o mesmo problema divide o histórico de um cliente em dois registros e manda duas pessoas responderem a uma única pergunta. Para este guia, li do início ao fim a documentação da Salesforce sobre fusão e threading de e-mail. Com o eesel CLI, um agente de código pode enviar a política aprovada de fusão e tratamento de duplicados como conhecimento, e depois fazer perguntas de teste para checar as respostas antes de qualquer coisa ir para produção. Conectar a própria org da Salesforce ainda exige alguém com permissões de admin para aprovar.
O que a fusão de casos da Salesforce realmente faz?
Ela junta até três casos em um, mantendo o que você escolher como principal. O artigo sobre a fusão da Salesforce diz que você compara os valores dos campos, seleciona os que quer no principal, e que «todas as listas relacionadas, itens do feed e registros filhos são adicionados ao principal».
O que acontece com os outros casos é uma decisão do admin. Se a org estiver configurada para excluir duplicados, eles são excluídos de forma reversível e ficam 15 dias na lixeira. Se ela os mantém, a palavra «Merged» é adicionada ao assunto no Highlights panel, e um link no duplicado leva ao caso principal.
A Salesforce ainda classifica isso sob Service Cloud, mas o nome de produto mais novo é Agentforce Service. O objeto Case e o recurso de fusão são os mesmos, então procure pelos dois nomes quando for buscar documentação. Se você é novo no objeto em si, meu guia de sistema de tickets da Salesforce cobre como os casos chegam e se movem.
Como fazer a fusão de casos duplicados passo a passo?
Existem três pontos de entrada, e todos limitam a seleção a três casos. A Salesforce documenta cada um na mesma página de fusão:
- Pela visualização de lista Cases. Selecione até três casos, clique em Merge Cases, escolha o principal na janela Compare Cases, selecione os valores dos campos e depois clique em Next e Merge.
- Pelo registro de um Case. Abra o caso, use o menu do Highlights panel, clique em Merge Cases e procure os casos para fundir. Esse é o caminho quando o duplicado não está na sua visualização de lista atual.
- Por uma lista relacionada em qualquer objeto padrão. Abra uma conta, escolha View All no painel de Cases, selecione até três casos e clique em Merge Cases.
Os agentes precisam de Read, Create, Edit e Delete sobre casos, segundo a tabela de permissões dessa página. Se o botão estiver faltando, o primeiro suspeito é a configuração de admin abaixo, não o perfil do agente.
Como configurar a fusão de casos no Lightning?
Ative a configuração, decida o que acontece com os duplicados, e coloque a ação onde os agentes possam encontrá-la. O artigo de configuração da Salesforce diz que você precisa tanto de Manage Cases quanto de Customize Application, e então:
- No Setup, digite
Case Mergeno Quick Find e selecione Case Merge. - Ative Merge Cases para chegar às configurações.
- Escolha Delete duplicate cases after merge, ou mantenha os duplicados e atribua um status pela lista Merged Case Status (ou adicione um próprio com Add a Case Status).
- Adicione a ação Merge Cases à página do registro de caso e o botão Merge Cases à visualização de lista.
- Opcionalmente, adicione uma lista relacionada Merged Cases ao layout do caso, pelo Object Manager como qualquer outra lista relacionada.
Nessa captura, a opção Keep aparece marcada como recomendada. Eu concordo: mantenha os duplicados com status Merged até confiar no seu processo. Duplicados excluídos saem da lixeira depois de 15 dias, e como uma fusão não pode ser desfeita, um duplicado mantido é a única trilha de auditoria que você terá se um agente escolher o principal errado.
O que se perde ou fica de fora em uma fusão?
Bastante coisa está documentada, e parte é fácil de passar batido. O artigo de configuração lista estas limitações:
| Limitação | O que isso significa para você |
|---|---|
| Não é possível desfazer uma fusão | Confira o principal e as escolhas de campos na tela de comparação antes de clicar em Merge |
| Case Milestones, Case Share e Case Team não são fundidos | O principal mantém apenas seu próprio relógio de SLA e sua própria equipe |
| Os anexos não são suportados e podem ser excluídos | Salve primeiro qualquer arquivo que precisar do duplicado |
| A janela Compare Cases mostra só os primeiros 35 campos de lookup do layout | Um lookup além desse limite não pode ser escolhido no momento da fusão |
| As Actions e Recommendations do caso principal são duplicadas | Espere sugestões dobradas depois de uma fusão |
| Casos pendentes em uma fila do Omni-Channel, ou atribuídos com status Opened ou Assigned, não podem ser fundidos | Veja a seção sobre Omni-Channel abaixo |
Dois desses pontos mudam como eu escolheria um principal. Como milestones não se movem, escolha o caso cujo entitlement e relógio de SLA sejam os reais, geralmente o mais antigo. Meu guia de entitlements e milestones explica por que um caso sem entitlement não ganha relógio nenhum. E como os anexos estão em risco, trate a fusão como o momento de mover arquivos manualmente. Um caso fundido pode acabar com um feed longo, então os resumos de casos com IA ajudam o próximo agente a se atualizar rápido.
Um detalhe de e-mail também importa. As considerações sobre threading da Salesforce dizem que, depois que dois casos são fundidos, todos os e-mails seguintes se vinculam ao case pai, mesmo que fossem sobre o filho, e quem decide qual caso é o pai é o agente que faz a fusão.
É possível fundir um caso que está esperando em uma fila do Omni-Channel?
Por padrão não, e uma configuração beta muda isso para casos não abertos. A limitação padrão bloqueia duplicados pendentes em uma fila do Omni-Channel ou atribuídos a agentes com status Opened ou Assigned. O artigo beta da Salesforce adiciona uma caixa de seleção na configuração do Case Merge que permite casos Pending Routing e Assigned, e continua bloqueando os Opened.
Esse duplicado pode ser fundido?
Escolha a configuração beta e onde o duplicado está no Omni-Channel. A resposta segue as regras documentadas pela Salesforce.
O motivo dessa linha é o ciclo de vida do roteamento. Quando um agente aceita um item de trabalho, o caso entra em andamento, e uma fusão feita por outra pessoa poderia sobrescrever a sessão daquele agente. O erro mostra «We couldn't merge these cases. One or more of the duplicate cases is currently being worked on», e a solução é o agente fechar a aba ou liberar o item de trabalho. A Salesforce classifica esse recurso como beta sob seus Beta Services Terms, então eu testaria primeiro em um sandbox. Meu guia de roteamento do Omni-Channel cobre os registros de roteamento pendente e atribuição por trás desses estados.
De onde vêm os casos duplicados?
Principalmente de e-mails que não correspondem a um caso existente. A página de threading do Email-to-Case da Salesforce explica a ordem de correspondência. No threading do Lightning, um e-mail recebido é comparado primeiro por um token de 23 caracteres no assunto ou no corpo. Se isso falhar, a Salesforce verifica os cabeçalhos In-Reply-To, References e Thread-Index. Se os dois falharem, ela cria um caso novo.
A página de limitações nomeia as formas em que a correspondência falha:
- Um cliente edita o assunto. Dependendo do cliente de e-mail, mudar o assunto pode remover o token de threading e causar um caso novo.
- Mais de um endereço de roteamento. A Salesforce diz para pedir aos clientes que escrevam para um único endereço, e afirma que enviar para vários causa resultados inesperados e não é suportado.
- Relés e servidores de e-mail que alteram cabeçalhos. Um relé que muda o Message-ID da Salesforce precisa mover o original para o cabeçalho References, e um agente de transferência de e-mail personalizado que remove References ou In-Reply-To pode causar casos novos.
- Threading antigo por Ref ID. Sem threading do Lightning ou baseado em cabeçalhos, uma resposta sem seu Ref ID cria um caso novo. A Salesforce classifica o threading por Ref ID como só de manutenção e recomenda a troca.
- Um sandbox atualizado. Se o ID da org muda, o token vinculado ao ID antigo da org para de funcionar.
O threading cobre e-mail. Para formulários web e canais de mensagens, não encontrei um mecanismo de correspondência comparável na documentação da Salesforce que li, então eu assumiria que um cliente que envia duas vezes, ou inicia uma segunda sessão, pode acabar com um segundo caso. Confira isso na sua própria org antes de confiar nisso. Se os duplicados vêm de várias pessoas olhando para uma mesma caixa, o ticket swarming é um problema relacionado. Para saber onde esses canais chegam, veja meu guia sobre Enhanced Messaging.
A Salesforce consegue sugerir duplicados antes que os agentes os encontrem?
Sim, em um beta chamado Enhanced Case Merge. O artigo da Salesforce sobre o Enhanced Case Merge descreve a mudança «de uma limpeza manual e reativa para uma prevenção proativa» em três passos:
- Na configuração do Case Merge, marque Merge cases with Enhanced Case Merge.
- Em Duplicate Rules, dê um nome a cada regra, escolha uma matching rule que decide como os duplicados são identificados, e defina as condições que um caso precisa cumprir antes que a regra seja executada.
- Arraste o componente Duplicate Cases para a página do registro de caso no Lightning App Builder.
O componente então lista duplicados prováveis com número do caso, assunto, contato e data de abertura, além de um botão que abre a janela de fusão com o caso atual pré-selecionado como principal. É um beta, então o mesmo conselho de testar primeiro em um sandbox se aplica. Ele também mantém a fusão nas mãos de uma pessoa, que é exatamente onde eu a manteria.
Como a IA pode reduzir os casos duplicados?
Respondendo mais rápido e apontando para o original, não fazendo a fusão por conta própria. Uma fusão não pode ser desfeita, então eu nunca deixaria um agente de IA fazer uma sem supervisão. O que um agente pode fazer com segurança é ler o caso novo, buscar nos seus outros casos, e deixar uma nota privada do tipo «isso parece o caso aberto hoje de manhã pelo mesmo contato». A integração da eesel com a Salesforce funciona assim dentro da org: ela lê casos e artigos do Knowledge, redige respostas como comentários internos do caso, e pode primeiro consultar a conta e buscar em outros casos, segundo sua documentação. Seu agente só vê o que o usuário autorizado da Salesforce pode ver, então as permissões de objeto e campo continuam sendo o limite real.
Esse limite se encaixa em qualquer revisão de governança de IA que você já faça. As próprias limitações de IA da Salesforce valem a pena ler antes de escolher uma camada.
Duas histórias de clientes mostram o mesmo padrão em outros helpdesks. A Rúngne opera três agentes no Gorgias, onde e-mail, chat e comentários sociais compartilham uma única fila. Em um mês, seus agentes trataram cerca de 2.100 tickets, marcaram cerca de 880 com tags, deixaram cerca de 580 respostas em rascunho como notas internas, e responderam diretamente a cerca de um em cada sete tickets. Ruído como comentários publicitários, respostas de ausência e spam é marcado e fechado, então nunca se torna um segundo registro para limpar, uma tarefa mais próxima da classificação de tickets do que da fusão. Na SamCart, um agente do Freshdesk envia a primeira resposta só quando ainda não há colega atribuído. Minha leitura é que uma primeira resposta rápida reduz os follow-ups do tipo «alguma novidade?» que tantas vezes se tornam duplicados, embora nenhuma das duas histórias meça duplicados diretamente.
Para respostas mais rápidas, veja meu guia de automação da primeira resposta. Para menos tickets no geral, veja desvio de tickets.
Para a mesma ideia em outras plataformas, veja meu guia de deduplicação de tickets. A versão do Freshdesk para essa tarefa está em fusão de tickets do Freshdesk.
Se sua fila já está cheia de ruído antes de duplicar, comece pela filtragem de spam. Minha comparação de caixas compartilhadas cobre o lado da entrada.
O que eu configuraria primeiro?
Prevenir primeiro, depois tornar a limpeza segura. Esta é a ordem que eu usaria em uma org do Service Cloud:
- Verifique seu método de threading. Se o Setup mostra configurações de «Insert thread ID», você está no threading por Ref ID. Mude para o threading do Lightning, e ative tanto a opção de token quanto a de cabeçalhos.
- Reduza os endereços de roteamento. Um endereço por caixa voltada ao cliente, e diga aos clientes para não copiarem vários.
- Ative o Case Merge com Keep selecionado. Adicione um status Merged claro, a ação, o botão de lista e a lista relacionada Merged Cases.
- Escreva uma regra de caso principal. A minha é: o caso mais antigo com um entitlement válido, e mover os anexos manualmente primeiro.
- Treine os agentes na regra do Omni-Channel. Casos com status Opened não podem ser fundidos, então libere o item de trabalho antes de uma fusão.
- Teste o Enhanced Case Merge em um sandbox. Comece com uma única regra de duplicados bem restrita.
- Adicione uma camada de notas de IA. Deixe um agente sinalizar os originais prováveis, e mantenha o clique de fusão nas mãos de um agente humano. Passe os casos realmente difíceis com a escalada por IA.
Se sua preocupação é quanto o Service Cloud custa quando esses add-ons se acumulam, meu detalhamento de preços cobre as edições. Para ver o que mais você pode automatizar no objeto Case, veja automação de casos da Salesforce. Para a visão mais ampla, comece com IA para helpdesk.
Experimente a eesel para Salesforce Service Cloud
Se os casos duplicados estão consumindo o tempo dos seus agentes, a eesel funciona como uma nova contratação que se conecta à sua org do Service Cloud, lê cada caso novo junto com o histórico da conta, e deixa um rascunho ou uma nota «possible duplicate of» como comentário interno. Seus agentes mantêm a decisão de fusão, e seu admin mantém o controle do que o agente pode ver. Grátis para testar.
