Mensagens por meio de registros relacionados
Muitos objetos dos quais você quer enviar mensagens não têm telefone próprio. Uma Oportunidade não tem telefone, mas tem uma pesquisa para o Contato que o possui. Uma Reserva também não tem telefone; o Contato do inquilino tem. O REDA Connect resolve isso com dois campos da configuração de objeto: um indica o campo de pesquisa para o registro da pessoa e o outro fornece o caminho por essa pesquisa até o telefone. Assim você tem um Feed Connect funcional na Oportunidade sem copiar telefones para esse objeto.
Há um comportamento que você precisa entender antes de configurar, pois surpreende na primeira vez: a mensagem é vinculada ao registro onde fica o telefone, o Contato, com seu registro original, a Oportunidade, como pai, e não o contrário. Ambos mostram a conversa em seus feeds. O exemplo completo abaixo mostra onde fica cada coisa; o comportamento é idêntico no envio e no recebimento.
- Leia primeiro Configurar qualquer objeto: este artigo apenas adiciona a variante de registros relacionados àquele procedimento.
- Seu objeto precisa de um campo de pesquisa para o registro que contém o telefone, por exemplo, um campo Contato principal da Oportunidade que pesquise um Contato.
Os dois campos que fazem funcionar
Usamos o exemplo da própria ajuda do produto: uma Oportunidade cujo telefone fica no Contato do campo de pesquisa Contato principal, com nome de API Primary_Contact__c:
| Campo da configuração | Valor | Significado |
|---|---|---|
| Nome de API do objeto | Opportunity | Você configura a Oportunidade: é onde os agentes trabalham. |
| Nome API campo do registro individual | Primary_Contact__c | O campo de pesquisa da Oportunidade que aponta para o registro da pessoa. |
| Nome de API do campo de telefone | Primary_Contact__r.MobilePhone | O caminho por meio dessa pesquisa até o telefone: o nome de relacionamento da pesquisa, que é seu nome de API trocando __c por __r, um ponto e o campo de telefone do Contato. |
| Nome de API do campo Name | Name | Use o Name da própria oportunidade neste percurso. Um caminho como Primary_Contact__r.Name exige verificar todos os percursos de entrada e saída usados; suportar um telefone relacionado não garante o mesmo suporte para o nome em todos eles. |
A ajuda de Nome API campo do registro individual descreve exatamente esse padrão: “Informe o valor se a mensagem desta configuração for enviada em um caso em que os detalhes do telefone residem em um objeto relacionado. Por exemplo, Opportunity possui um campo "Primary_Contact__c" que é um lookup para um registro de Contact. Se você quiser enviar uma mensagem associada a Opportunity, informe o valor como "Primary_Contact__c" e o campo Phone como "Primary_Contact__r.MobilePhone".”
Todo o restante —canal, prioridade, descrição e indicador ativo— funciona exatamente como em Configurar qualquer objeto.
Some_Field__c, o prefixo do caminho é Some_Field__r.; para uma pesquisa padrão como ContactId é Contact.. O campo de telefone no final do caminho deve seguir a regra de formato internacional somente com dígitos: Como inserir números de telefone.
Onde a mensagem é vinculada: a regra
Sempre que uma configuração tiver Nome API campo do registro individual definido e a pesquisa do registro estiver preenchida, o REDA Connect vincula cada mensagem da conversa assim:
- Registro da mensagem = o registro da pessoa relacionada, o Contato onde fica o telefone.
- Registro pai da mensagem = o registro que você configurou, a Oportunidade.
O Feed Connect mostra a conversa nos dois registros. Como o registro da mensagem é um Contato, o REDA Connect também cria seu vínculo automático com Contato: funcionam a proteção de recusa e os relatórios por Contato. Essa é a razão dessa forma de vincular: a conversa pertence à pessoa, enquanto a Oportunidade fornece o contexto.
A mensagem e a resposta mantêm registro = Contato e pai = Oportunidade somente se a pesquisa de entrada selecionar a mesma configuração e contexto. Uma configuração Contato prioritária ou várias oportunidades com o mesmo número podem vincular a resposta de outra forma.
Exemplo prático: antes e depois
Configuração: a Oportunidade “Sunset Villa – Unit 12” tem Contato principal = Contato “Dana Reyes”, cujo Celular é 971501234567. A configuração acima está ativa para WhatsApp.
Um agente envia pela Oportunidade. Ele a abre, escreve “Olá Dana, sua visita está confirmada para quinta-feira às 16h” no Feed Connect e envia.
| Onde você olha | O que você vê |
|---|---|
| O próprio registro da mensagem. | Vinculado a Dana Reyes (Contato); registro pai Sunset Villa – Unit 12 (Oportunidade). |
| Feed Connect da Oportunidade. | A mensagem, no histórico da conversa. |
| Feed Connect do Contato de Dana. | A mesma mensagem, no mesmo histórico. |
| O telefone de Dana. | A mensagem do WhatsApp. |
Dana responde: “Perfeito, até lá”.
| Onde você olha | O que você vê |
|---|---|
| O registro da mensagem de resposta. | Vinculado a Dana Reyes (Contato); registro pai Sunset Villa – Unit 12 (Oportunidade). |
| Feed da Oportunidade e do Contato. | A resposta aparece no mesmo histórico em ambos. |
A parte pouco intuitiva: se executar um relatório ou uma exibição de mensagens por registro, essa conversa conta no Contato, não na Oportunidade; a Oportunidade aparece como pai. Se esperava que “mensagens na Oportunidade” significasse registro = Oportunidade, ajuste o relatório para incluir também o lado do registro pai.
Solução de problemas
| Sintoma | Causa | Correção |
|---|---|---|
| O feed da Oportunidade mostra “Nenhuma conta Connect ou número de telefone ativo foi encontrado para os canais de mensagens.” | A pesquisa, por exemplo, Contato principal, está vazia neste registro ou o telefone do Contato está vazio. | Preencha a pesquisa e o campo de telefone. |
| O envio falha ou nenhum registro é encontrado no recebimento. | O caminho de relacionamento está incorreto: __c em vez de __r ou um erro no nome do campo. | Revise Nome de API do campo de telefone no Gerenciador de objetos; o caminho é <nome de relacionamento da pesquisa>.<campo de telefone>. |
| A conversa aparece no Contato, mas você não a encontra “na” Oportunidade nos relatórios. | A regra de vínculo funciona como projetada: registro = Contato e pai = Oportunidade. | Faça o relatório pelo lado do registro pai ou leia a seção acima. |
| A resposta chegou ao Contato, mas sem a Oportunidade como pai. | A resposta correspondeu primeiro a outra configuração, por exemplo, uma de Contato direto com maior prioridade. | Revise sua ordem de prioridade: a configuração que vence a correspondência decide o vínculo. |
Perguntas frequentes
Elas servem a fins diferentes e podem coexistir. Mas ambas podem corresponder ao mesmo telefone nas mensagens recebidas: vence a de maior prioridade e decide como a mensagem é vinculada. Ordene-as deliberadamente: coloque esta acima de Contato direto se quiser as respostas associadas ao contexto da Oportunidade.
Esses registros não podem enviar mensagens porque não há telefone de destino. O feed informa ao agente que não foi encontrado um número. Considere tornar a pesquisa obrigatória nos registros que precisam de mensagens.
Caminhos de telefone com vários níveis podem ser usados se cada relacionamento e campo for válido e preenchido. Mantenha cadeias curtas e teste ambos os sentidos. Não presuma o mesmo suporte para o nome em todos os processos; alguns o leem diretamente do objeto configurado. Um vínculo vazio impede ler o telefone por esse caminho.
Sim: o mecanismo é independente do canal. Crie a configuração do canal SMS com os mesmos dois valores de campo.
Próximos caminhos
- Como as mensagens recebidas encontram seu registro: como esta configuração compete com outras quando chega uma resposta.
- Atribuir mensagens recebidas aos proprietários dos registros: em configurações relacionadas, decidir qual proprietário, o do registro correspondente, recebe a mensagem.
- Configurar qualquer objeto: o procedimento base ampliado por este artigo.