Integração entre ServiceNow e Salesforce: guia passo a passo

O guia oficial de 13 de maio de 2026 propõe um fluxo de incidente do ServiceNow para caso no Salesforce, seguido da gravação do ID do caso no incidente e de uma notificação ao responsável.

Essa gravação de referência não é uma sincronização bidirecional completa. Para propagar alterações futuras do Salesforce de volta ao ServiceNow, seria necessário definir outro fluxo e regras de conflito. Aqui, o escopo é o percurso descrito acima.

Requisitos confirmados na documentação

As páginas de ServiceNow e Salesforce foram consultadas em 26/09/2026.

• O Help do ServiceNow informa que o aplicativo está disponível no plano Enterprise do Make. Essa é uma condição do conector documentada no Help, não uma conclusão inferida da página de preços.
• Confirme acesso à instância e autorização para ler incidentes e gravar o campo de referência.
• A documentação do Salesforce alerta que nem todas as edições têm acesso à API. Confirme a elegibilidade e as permissões da sua organização antes de conectar.
• Prepare uma instância de teste e um sandbox Salesforce para validar os mapeamentos.

Para orçamento, consulte separadamente os planos e condições comerciais atuais do Make.

1. Conecte o ServiceNow

Adicione ServiceNow > Watch Records. A documentação oferece conexão com usuário e senha e uma opção OAuth com credenciais de cliente. Siga o procedimento correspondente aprovado pela sua organização; não classifique uma opção como obrigatória em toda produção sem avaliar a política local.

No campo de subdomínio, para uma instância como yourinstance.service-now.com, informe apenas yourinstance. Configure a tabela incident.

O fluxo inicial usa consulta periódica. Um fluxo por webhook exige configuração própria no ServiceNow e no Make; selecionar Watch Records não cria automaticamente uma Business Rule.

2. Defina quais incidentes entram

Coloque um filtro na ligação entre módulos, não um suposto módulo chamado “Filter”. A documentação de filtros descreve esse comportamento.

O artigo sugere categoria de atendimento ao cliente e exclusão de incidentes resolvidos. Os valores internos de category e state devem ser conferidos na sua instância. Não copie “customer” ou um número de estado como regra universal.

Inspecione os campos de saída, como sys_id, number, short_description, description, caller_id e priority. A referência de conta precisa existir no seu modelo de dados; nem todo incidente tem um campo account utilizável.

3. Localize a conta no Salesforce

Use Salesforce > Search Records (SOQL) para procurar a conta correspondente. Prefira um identificador externo previamente acordado entre os sistemas; nomes de empresa podem divergir ou se repetir.

Solicite pelo menos Id e OwnerId, além do campo de correspondência necessário. Trate resultados ambíguos como revisão manual, não como escolha automática da primeira conta.

A origem propõe uma rota para contas não encontradas. Atenção editorial: um router depois de uma busca que não produz bundles não recebe dados para encaminhar. Teste a configuração de continuidade sem resultados, quando disponível, ou outro tratamento explícito que preserve o incidente e registre a ausência. Não presuma que adicionar um router resolva esse caso.

4. Crie ou atualize o caso

A documentação atual lista Create a Record, Update a Record e Create or Update a Record; o artigo usa também o termo “Upsert”. Selecione o módulo adequado à versão e ao identificador externo preparado.

Não copie uma escala fixa de prioridades nem suponha que “ServiceNow” já seja um valor permitido em Origin. Valide as listas de valores da organização.

Use um identificador externo único do incidente para reconhecer reprocessamentos. Isso ajuda a controlar duplicatas, mas não dispensa teste de concorrência e das regras de unicidade.

5. Grave a referência no incidente

Adicione ServiceNow > Update a Record para a tabela incident, usando o sys_id original. Mapeie o ID do caso criado ou encontrado para um campo preparado pelo administrador, por exemplo u_salesforce_case_id.

Esse nome é um exemplo da fonte, não um campo garantido. Evite que a gravação dessa referência inicie um ciclo sem fim de atualizações.

6. Notifique o responsável

A fonte propõe uma tarefa Salesforce, mensagem Slack ou e-mail. Para uma tarefa, configure Create a Record no objeto Task:

• Subject: número e resumo do incidente.
• WhatId: referência da conta ou registro escolhido no desenho.
• OwnerId: responsável retornado pela busca.
• ActivityDate: prazo definido pela equipe.

“Próximo dia útil” exige uma regra de calendário; somar um dia não trata feriados e fins de semana automaticamente.

7. Teste antes de ativar

Execute Run once no ambiente de teste. Confira os bundles, o filtro, a conta, o caso, a referência de retorno e a notificação. Inclua incidentes repetidos, conta ausente, valores de prioridade inesperados e falha de autenticação.

Depois ajuste o agendamento e o acompanhamento de erros. Não declare o cenário pronto para produção apenas porque uma execução ficou verde.

Extensões e segurança

O artigo sugere alertas de SLA para contas estratégicas e oportunidades de renovação relacionadas a ativos. Esses são novos escopos: exigem seus próprios campos, permissões e critérios, não a simples troca do nome da tabela.

Recomendações editoriais: use credenciais dedicadas, conceda apenas os acessos necessários, mantenha segredos fora de mensagens e revise o acesso quando a integração for desativada. Para volumes maiores, meça o comportamento antes de aumentar paralelismo; um Data Store não deve ser anunciado como fila sem perda apenas por estar no desenho.

Fonte

Make — ServiceNow Salesforce integration, publicado em 13/05/2026 e capturado em 16/05/2026. Corrigimos as promessas de sincronização completa e de ausência garantida de duplicatas, além de distinguir nomes históricos e atuais. Não houve autenticação nem escrita em sistemas reais.