13 de maio de 2026 | 8 minutos

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

Crie uma integração ao vivo entre ServiceNow e Salesforce no Make. Sincronize incidentes com cases, mapeie contas e automatize notificações sem código personalizado ou middleware. ![How to Integrate ServiceNow and Salesforce: A Step-by-Step Automation Guide](__CODE_BLOCK_0__ Every time a critical incident hits ServiceNow and your account team in Salesforce has no idea, you're flying blind. Customer escalations get missed. Sales reps walk into renewal calls without knowing their account has open P1 tickets. IT and revenue teams operate on separate data; someone manually reconciles the gap. This guide shows you how to build a ServiceNow Salesforce integration using Make: a Scenario that automates your ServiceNow Salesforce sync end-to-end. Incidents trigger Salesforce Case creation, account owners get notified, and data writes back to ServiceNow automatically. No custom code, no middleware.

What is a ServiceNow Salesforce integration?

A ServiceNow Salesforce integration is a bidirectional data sync between your IT service management platform and your CRM. When a record changes in one system, the corresponding record in the other updates automatically: no manual entry, no tab switching, no reconciliation at the end of the day. The core problem it solves is organizational siloing. A P1 incident raised in ServiceNow against a customer account is invisible to the account executive in Salesforce. They walk into a renewal call with no idea their customer has had three open tickets for two weeks. Support agents log the same data twice. SLA response slows because the people who need to act are the last to know. The three object pairs that matter most in practice are: | ServiceNow | Salesforce | Sync direction | | --- | --- | --- | | Incident | Case | Bidirectional | | Configuration Item | Account | ServiceNow → Salesforce | | User | Contact | Bidirectional | Architecturally, there are two approaches worth understanding before you build: * Event-driven sync: fires the moment a record changes in ServiceNow; requires webhook or Business Rule configuration but delivers real-time accuracy * Scheduled sync: polls ServiceNow on a set interval; simpler to configure but introduces latency

Which you choose depends on your SLA requirements and your ServiceNow admin's access level. This guide covers both, using Make's Scenario Builder as the integration layer. You can see the full list of available ServiceNow modules [here](__CODE_BLOCK_1__ For the full Salesforce REST API endpoint reference used throughout this guide, see the[ ](__CODE_BLOCK_2__ ![servicenow-salesforce-object-mapping-diagram](__CODE_BLOCK_3__

How to build a ServiceNow Salesforce integration in Make (step-by-step)

Ao final desta seção, você terá um cenário ativo no Make que monitora incidentes novos ou atualizados no ServiceNow e cria ou atualiza um case correspondente no Salesforce. Em seguida, ele grava o ID do case do Salesforce de volta no incidente original do ServiceNow e notifica automaticamente o responsável pela conta no Salesforce. Antes de começar, confirme que você tem o seguinte disponível: * Conta Make no plano Enterprise (obrigatório para o app ServiceNow, conforme a documentação mais recente. * Instância do ServiceNow com acesso de administrador, seja uma instância de desenvolvedor ou uma instância de produção em que você possa gerenciar funções de usuário e recuperar a URL da sua instância, nome de usuário e senha * Conta Salesforce em uma edição que inclua acesso à API REST; nem todas as edições se qualificam, então verifique a sua antes de conectar * Familiaridade básica com a estrutura da tabela de incidentes do ServiceNow e com os objetos Case e Account do Salesforce

![Integration-ServiceNow-Salesforce-Make-05-13-2026 04 14 PM](__CODE_BLOCK_5__ A note before you build: The ServiceNow app on Make is available on the [Enterprise plan](__CODE_BLOCK_6__ only. Confirm your Make plan before starting. On the Salesforce side, not all Salesforce editions include API access; verify yours supports REST API calls before attempting to connect.

Step 1: Connect your ServiceNow account in Make

The goal of this step is to authenticate Make against your ServiceNow instance so it can read and write incident data via the ServiceNow REST API. In your Make Scenario Builder, add the ServiceNow > Watch Records module as your trigger. Click Add next to the Connection field. Make provides two connection methods: | Connection type | When to use | | --- | --- | | Basic Auth (username + password) | Apenas para instâncias de teste e de desenvolvedor | | OAuth 2.0 (credenciais do cliente) | Todos os ambientes de produção | Para OAuth 2.0, localize o campo Sub Domain e insira apenas a parte do subdomínio da sua URL do ServiceNow. Por exemplo, se a URL da sua instância for ‘yourinstance.service-now.com’, insira apenas ‘yourinstance’. A parte ‘.service-now.com’ é adicionada automaticamente pelo Make. Cole seu Client ID e Client Secret em seus respectivos campos e, em seguida, clique em Save. Depois de conectado, defina o campo Table como ‘incident’. Isso informa ao módulo qual tabela do ServiceNow deve ser monitorada. Para o tipo de gatilho, você tem duas opções: polling (o Make verifica o ServiceNow em um intervalo agendado) ou webhooks (o ServiceNow envia as alterações ao Make em tempo real). Webhooks exigem que um administrador do ServiceNow configure uma Business Rule de saída, e instâncias gratuitas de desenvolvedor normalmente não oferecem suporte a eles. Comece com polling e migre para webhooks assim que o cenário for validado em produção. ![Integration-ServiceNow-Salesforce-Make-05-13-2026 04 18 PM](__CODE_BLOCK_7__

Step 2: Filter for relevant incident records

Without a filter, your Scenario processes every incident created or updated in ServiceNow, including internal IT tickets with no customer relevance. This inflates your operation count and creates noise in Salesforce. The filter narrows scope to only the records that matter. After the Watch Records module, add a Filter module. The recommended starting logic is: | Field | Operator | Value | | --- | --- | --- | | category | Equal to | customer | | state | Not equal to | 6' (Resolved) | Ambas as condições devem ser definidas com lógica AND para que apenas incidentes em aberto e de atendimento ao cliente passem. Esses nomes de campo são nomes de API, não os rótulos exibidos que você vê na interface do ServiceNow. Esta é uma das fontes mais comuns de erros de configuração: o campo rotulado como "Caller" no ServiceNow é 'caller_id' na API; "ID" é 'sys_id'. Sempre use os nomes de API ao mapear campos no Make. O pacote de saída da Etapa 1 contém os seguintes campos disponíveis para mapear em seu filtro e em todos os módulos subsequentes: * 'sys_id', 'number', 'short_description', 'description' * 'caller_id', 'account', 'priority', 'state', 'category'

![Integration-ServiceNow-Salesforce-Make-05-13-2026 04 24 PM](__CODE_BLOCK_8__

Step 3: Look up the matching Salesforce account

Before creating a case in Salesforce, you need to identify which account the incident belongs to. Creating a case without a parent account breaks the data model and makes the record effectively invisible to account teams. Add the Salesforce > Search Records (SOQL) módulo após o filtro. Defina o objeto como 'Account' e pesquise por nome da empresa ou por um campo personalizado de ID externo. As duas abordagens são: | Método de busca | Ideal para | | --- | --- | | Correspondência pelo nome da empresa | Começar rapidamente; menos preciso | | ID externo personalizado (por exemplo, 'ServiceNow_Account_ID__c') | Ambientes de produção; confiável e exato | Se sua org do Salesforce já armazena uma referência de conta do ServiceNow como um campo personalizado, use isso. A correspondência por nome introduz risco se os nomes das empresas forem formatados de maneira diferente nos dois sistemas. Depois desse módulo, adicione um roteador para lidar com ambos os resultados: * Caminho 1: Conta encontrada — prossiga para a criação do case na Etapa 4 * Caminho 2: Nenhuma conta encontrada — registre os detalhes do incidente em um canal do Slack ou em uma planilha do Google Sheets para revisão manual; não prossiga para a criação do case

Ignorar o caminho sem correspondência é um erro comum. Sem ele, seu cenário falhará sem exibir erro claro quando uma conta não reconhecida aparecer. A lista completa dos módulos disponíveis do Salesforce, incluindo Search Records, está documentada na documentação do app Salesforce no Make.

Etapa 4: Criar ou atualizar o case do Salesforce

O objetivo desta etapa é gravar os dados do incidente do ServiceNow em um registro de case do Salesforce. No caminho "Conta encontrada" do seu roteador, adicione o módulo Salesforce > Create a Record e defina o objeto como 'Case'. Mapeie os seguintes campos a partir do pacote do ServiceNow: | Campo do Salesforce | Origem | Observações | | --- | --- | --- | | Subject | short_description | Mapeamento direto | | Description | description | Mapeamento direto | | Priority | priority | Requer transformação (veja abaixo) | | AccountId | Account 'Id' da etapa 3 | Crítico: o case ficará órfão sem isso | | Origin | Codificado: 'ServiceNow' | Permite filtrar no Salesforce por origem | A escala de prioridade do ServiceNow vai de '1' (Crítica) a '4' (Baixa); o Salesforce espera 'Alta', 'Média' ou 'Baixa'. Use uma função de texto do Make ou um módulo de tabela de consulta entre os dois para transformar o valor antes que ele chegue ao registro do case. Sem essa etapa, o campo de prioridade gerará erro ou será preenchido incorretamente. Para cenários de re-trigger, em que o mesmo incidente dispara o cenário mais de uma vez, substitua o módulo Create a Record por Upsert a Record. Defina um campo de ID externo personalizado (por exemplo, 'ServiceNow_Incident_ID__c') como chave de correspondência. Isso evita que cases duplicados sejam criados em gatilhos subsequentes para o mesmo incidente.

Etapa 5: Gravar de volta no ServiceNow o ID do case do Salesforce

Esta etapa encerra a sincronização bidirecional. Depois que um case existe no Salesforce, o ID dele precisa ser armazenado no incidente original do ServiceNow. Isso permite que os agentes de suporte vejam rapidamente se existe um case, sem precisar acessar o Salesforce. Adicione o módulo ServiceNow > Update a Record e configure-o da seguinte forma: | Campo | Valor | | --- | --- | | Table | incident | | Record 'sys_id' | Mapeado a partir do pacote da etapa 1 | | Custom field | u_salesforce_case_id | | Custom field value | Id do case do Salesforce da etapa 4 | O campo 'u_salesforce_case_id' precisa ser criado no ServiceNow antes que esta etapa funcione. Um administrador do ServiceNow pode adicioná-lo via Studio ou System Dictionary. O prefixo 'u_' é a convenção de nomenclatura do ServiceNow para campos personalizados; qualquer campo criado pela sua org carregará esse prefixo automaticamente. Depois disso, todo incidente que passar pelo cenário passa a ter uma referência direta ao seu equivalente no Salesforce. Os agentes de suporte veem o ID do case no registro do incidente; sem buscas entre plataformas, sem troca de mensagens entre equipes perguntando se um case já foi aberto.

Etapa 6: Notificar o responsável pela conta no Salesforce

Assim que o case existir no Salesforce, o responsável pela conta precisa saber. Há três maneiras de lidar com essa notificação: | Método | Ideal para | | --- | --- | | Tarefa no Salesforce (recomendado) | Equipes que trabalham no Salesforce; mantém a atividade registrada na conta | | Mensagem no Slack | Organizações em que as equipes de contas respondem melhor no Slack do que no Salesforce | | E-mail do Gmail ou Outlook | Equipes sem Slack ou quando e-mail é o canal de escalonamento preferido | A abordagem recomendada é um módulo Salesforce > Create a Record definido para o objeto 'Task'. Mapeie os campos da seguinte forma: | Campo da tarefa | Valor | | --- | --- | | Subject | New ServiceNow Incident: ' + 'number' do pacote da etapa 1 | | WhatId | Account 'Id' do pacote da etapa 3 | | OwnerId | Account 'OwnerId' do pacote da etapa 3 | | ActivityDate | Hoje + 1 dia útil | Um ponto a confirmar antes de testar: o campo 'OwnerId' deve ser retornado explicitamente na sua consulta Search Records da etapa 3. Se ele não estiver incluído nos campos retornados pela sua consulta SOQL, ele não estará disponível no pacote e o mapeamento falhará sem exibir erro claro.

Etapa 7: Ativar, testar e agendar o cenário

Antes de habilitar o cenário em produção, valide-o de ponta a ponta com um incidente conhecido. No Scenario Builder do Make, clique em ‘Run Once’ e dispare o cenário usando um incidente real de uma instância de staging do ServiceNow apontada para um sandbox do Salesforce. Isso permite rastrear cada pacote em cada módulo sem gravar dados em sistemas de produção. Após a conclusão da execução, abra o painel ‘Execution History’ e verifique cada módulo quanto a: * Indicadores de status verdes confirmando a execução bem-sucedida * Saída de pacote em cada etapa para verificar se os mapeamentos de campos foram preenchidos corretamente * Quaisquer filtros removidos na etapa 2 que possam estar excluindo registros inesperadamente

Depois de validado, defina sua agenda de polling. A cada 15 minutos é uma cadência inicial razoável para a maioria das equipes; reduza esse intervalo se seus requisitos de SLA exigirem resposta mais rápida, ou aumente-o se o volume de incidentes for baixo e os custos de operação forem uma preocupação. Para ativar, alterne o cenário para On e configure os e-mails de notificação de erro integrados do Make nas configurações do cenário. Eles alertam você quando uma execução falha, para que os problemas não passem despercebidos entre os ciclos de polling. A orientação completa sobre agendamento e tratamento de erros está no .

Casos de uso comuns para a integração entre ServiceNow e Salesforce

O cenário de incidentes para case que você construiu nas etapas acima é a base. A mesma arquitetura — monitorar um registro do ServiceNow, localizar uma conta do Salesforce, criar ou atualizar um registro, notificar um membro da equipe — se aplica a uma ampla variedade de modelos de negócios e estruturas de equipe. Os dois casos de uso abaixo mostram como pequenas mudanças nas condições de gatilho e nos módulos de saída produzem resultados significativamente diferentes.

Caso de uso 1: alerta de escalonamento de SLA para contas corporativas

Uma grande empresa de SaaS gerencia dezenas de contas estratégicas, cada uma com um CSM dedicado. Quando um incidente de prioridade 1 é aberto em uma dessas contas no ServiceNow, o CSM precisa saber em minutos, não no final de um stand-up. O cenário filtra por 'priority' = '1' e por um campo personalizado de nível da conta que identifica contas estratégicas. Quando ambas as condições são atendidas, ele cria uma tarefa de alta prioridade no Salesforce atribuída ao CSM, envia uma mensagem direta no Slack com os detalhes do incidente e registra uma publicação no Chatter no registro da conta. O CSM recebe o contexto completo nas ferramentas que já usa, sem precisar de acesso ao ServiceNow.

Caso de uso 2: vinculação de ativo de TI a oportunidade para renovações

Uma equipe de operações de TI rastreia itens de configuração de hardware e software (CIs) no ServiceNow, incluindo datas de fim de vida útil. A equipe de vendas não tem visibilidade desses dados, então a abordagem para renovação é, no máximo, reativa. O cenário monitora registros de CI em que a sinalização de fim de vida útil foi definida, localiza a conta correspondente no Salesforce e cria uma oportunidade de renovação com o nome do ativo, o tipo e a data prevista de expiração já preenchidos. O executivo de contas recebe uma tarefa para iniciar o contato antes que o cliente comece a avaliar alternativas.

Melhores práticas para a integração entre ServiceNow e Salesforce

Uma integração em execução entre duas plataformas corporativas traz riscos operacionais reais. Corrupção de dados, operações descontroladas e incidentes perdidos são modos de falha previsíveis, não casos extremos. As duas práticas abaixo são as etapas de maior impacto que você pode adotar para projetar resiliência desde o início.

Dica 1: Use IDs externos para evitar registros duplicados

Cenários baseados em polling podem processar o mesmo incidente mais de uma vez se uma execução agendada se sobrepor a uma execução lenta. Para evitar isso, siga estas etapas: * Crie um campo de ID externo personalizado no objeto case do Salesforce, por exemplo 'ServiceNow_Incident_ID__c' * Preencha-o com o 'sys_id' do ServiceNow sempre que um case for criado ou atualizado * Use Salesforce > Upsert a Record em vez de Create a Record

A lógica de upsert verifica se já existe um registro com esse ID externo antes de gravar: se existir, ela o atualiza; se não existir, ela o cria. Executar a mesma operação duas vezes produz o mesmo resultado que executá-la uma vez, então cases duplicados nunca são criados.

Dica 2: Limite as permissões de API ao acesso mínimo necessário

Crie um usuário de integração dedicado tanto no ServiceNow quanto no Salesforce especificamente para o Make. No Salesforce, atribua um conjunto de permissões limitado apenas aos objetos de que o cenário precisa: cases, contas e tarefas. Não use um perfil de administrador do sistema. No ServiceNow, restrinja o acesso do usuário de integração à leitura na tabela 'incident' e à gravação apenas nos campos específicos que estão sendo atualizados. Audite as credenciais trimestralmente e revogue o acesso imediatamente se a integração for desativada ou se a conexão do Make for descontinuada.

Para onde ir a partir daqui

Agora você tem um cenário pronto para produção que conecta o gerenciamento de incidentes do ServiceNow ao Salesforce sem código personalizado ou middleware. As equipes de TI e de receita compartilham uma visão única e precisa da saúde do cliente: sem reconciliação manual, sem escalonamentos perdidos. Teste o cenário com um incidente real de um ambiente de staging e, em seguida, estenda-o usando o do Make para cobrir sincronização de ativos, gerenciamento de mudanças e automação de oportunidades. Se você ainda não configurou sua conta Make, e crie seu primeiro cenário hoje mesmo.

Perguntas frequentes

Q1: O Salesforce pode se integrar ao ServiceNow?

Sim. Salesforce e ServiceNow expõem APIs REST, o que significa que podem trocar dados diretamente ou por meio de uma plataforma de integração. A abordagem mais comum é conectá-los por uma camada de middleware como o Make, que cuida de autenticação, mapeamento de campos, tratamento de erros e agendamento sem código personalizado. O cenário construído neste guia é um exemplo funcional: incidentes no ServiceNow disparam a criação de cases no Salesforce, com sincronização de dados em ambas as direções.

Q2: O ServiceNow é um CRM ou ERP?

O ServiceNow não é um CRM tradicional nem um ERP; ele é, principalmente, uma plataforma de gerenciamento de serviços de TI e automação de fluxos de trabalho. O Salesforce é o CRM. O motivo pelo qual uma integração entre eles é valiosa é justamente porque eles atendem a funções diferentes: o ServiceNow gerencia incidentes, ativos e operações de TI, enquanto o Salesforce gerencia relacionamentos com clientes, contas e receita. Conectá-los oferece às equipes de TI e de receita uma visão compartilhada da saúde do cliente.

Q3: Que dados podem ser sincronizados entre ServiceNow e Salesforce?

Os objetos mais comuns sincronizados em uma sincronização de dados ServiceNow Salesforce são incidentes com cases, itens de configuração com contas, usuários com contatos e solicitações de mudança com oportunidades. Quais objetos estão disponíveis depende de quais módulos do ServiceNow sua org licencia e de como sua instância do Salesforce está configurada; nem toda org tem as mesmas tabelas ou objetos personalizados em uso. Comece com a sincronização de incidente para case coberta neste guia e amplie a partir daí quando a base estiver estável.

Q4: Por que meu módulo ServiceNow Watch Records não está disparando?

As causas mais comuns de um gatilho do ServiceNow no Make não funcionar são: usar um rótulo exibido em vez do nome da tabela da API (a tabela é 'incident', não "Incidents"); um intervalo de polling definido como muito longo; condições de filtro na etapa 2 que estão excluindo todos os registros; ou um token OAuth expirado. Abra primeiro o histórico de execuções do Make; ele mostra exatamente qual módulo parou e qual erro foi retornado, o que é mais rápido do que verificar qualquer uma das plataformas isoladamente.

Q5: Quanto tempo leva para construir essa integração e quanto ela custa em custos de operação no Make?

Um profissional competente de operações pode concluir a construção inicial do cenário em 2 a 4 horas. Reserve de 1 a 2 dias, incluindo testes de ponta a ponta em ambientes de staging. Quanto aos custos de operação, o total depende de quantos módulos são acionados por incidente e de quantos incidentes sua org processa diariamente; em vez de estimar aqui, confira para ver os limites de créditos atuais entre os níveis de plano e calcule com base no volume esperado. *

Q6: Posso construir essa integração com Zapier ou MuleSoft em vez disso?

Sim; ambos oferecem suporte a conexões com ServiceNow e Salesforce. O Zapier é adequado para sincronizações lineares de baixo volume, mas fica difícil de gerenciar quando a lógica exige roteadores, caminhos condicionais e gravações bidirecionais em vários objetos. O MuleSoft oferece uma governança de API mais profunda e é bem adequado para grandes empresas com equipes dedicadas de integração, mas exige recursos de desenvolvimento e prazos de implementação significativamente maiores. O Make fica entre os dois: o visual Scenario Builder lida com lógica de múltiplos ramos sem código, ao mesmo tempo que permanece acessível a profissionais de operações que não contam com suporte de engenharia.

Q7: Como faço para escalar isso para lidar com milhares de incidentes por dia?

Para escalar a automação entre ServiceNow e Salesforce além de uma configuração básica baseada em polling: mude de polling para webhooks configurando uma Business Rule no ServiceNow para enviar alterações ao Make em tempo real; habilite o processamento paralelo nas configurações do seu cenário do Make para lidar com pacotes concorrentes; use um armazenamento de dados do Make como fila para absorver picos de tráfego sem perder registros; e considere dividir o cenário monolítico em cenários filhos modulares chamados por meio do módulo HTTP do Make, o que torna cada etapa mais fácil de manter e depurar em escala.