14 de maio de 2026 | 8 minutos

Integração entre HubSpot e Salesforce: guia passo a passo (2026)

Pare de perder leads para dados de CRM desalinhados. Veja como criar uma sincronização confiável e bidirecional entre HubSpot e Salesforce. ![How to Integrate HubSpot and Salesforce in Make-](__CODE_BLOCK_0__ Your CRM and marketing platform are only as useful as the data flowing between them. When a HubSpot Salesforce integration is poorly configured, sales reps follow up on leads marketing already disqualified, contacts get duplicated, and attribution data falls apart. According to[ ](__CODE_BLOCK_1__ over 27% of marketers cite sales-marketing alignment as a top challenge. This guide covers how to build a reliable, configurable integration using Make.

What is a HubSpot Salesforce integration?

A HubSpot Salesforce integration is a bidirectional sync between the two platforms that keeps contacts, companies, deals, and activity data consistent across both systems. When a contact is created or updated in either platform, those changes propagate to the other, so sales and marketing always work from the same records. There are two main approaches to building this HubSpot Salesforce sync. The first is HubSpot's[ ](__CODE_BLOCK_2__ which handles standard object syncing with a point-and-click setup. It works well for teams with straightforward field mappings and standard sync rules. The second is a custom automation-layer approach using a platform like Make, which gives you full control over sync conditions, field transformations, routing logic, and error handling. For ops leaders and RevOps teams at companies with 50 to 500 employees, the native connector frequently hits its limits. Make addresses this through its visual Scenario Builder, where each step in your CRM integration automation is a configurable module. ![native-vs-make-integration-comparison](__CODE_BLOCK_3__

How to connect HubSpot and Salesforce using Make

Before you build, confirm you have the following in place: * An active HubSpot account with API access enabled (Professional or Enterprise tier) * Uma conta do Salesforce com credenciais de administrador ou um aplicativo conectado já configurado, com OAuth 2.0 habilitado * Uma conta ativa no Make

Você criará um cenário que monitora novos contatos ou contatos atualizados no HubSpot e, em seguida, cria ou atualiza o registro de lead correspondente no Salesforce. Uma verificação de deduplicação fica entre os dois módulos para evitar que registros duplicados apareçam em qualquer um dos sistemas. Se esta for sua primeira vez criando no Make, o guia) cobre tudo o que você precisa antes de continuar. Para o Salesforce, revise o guia) em help.salesforce.com antes de iniciar a Etapa 2, pois você precisará ter sua Consumer Key e sua Consumer Secret em mãos.

Etapa 1: Configure sua conexão com o HubSpot no Make

Abra o Make e crie um novo cenário. Adicione um módulo gatilho do HubSpot como primeiro passo usando o guia,) e, em seguida, selecione o tipo de gatilho com base no que você está sincronizando: * Use Watch Contacts para acionar o cenário quando um contato for criado ou atualizado no HubSpot * Use Watch CRM Objects se você precisar acompanhar alterações em outros tipos de objeto, como empresas ou negócios

Para autenticar, selecione 'Add a connection' e escolha OAuth 2.0. O Make abre a tela de autorização do HubSpot, onde você concede os escopos exigidos pelo cenário: no mínimo, leitura/gravação de contatos e objetos de CRM. OAuth 2.0 é a escolha certa para uso em produção porque oferece controle granular de escopos e permite revogar o acesso sem precisar trocar chaves de API em cada integração. Depois de conectado, defina o intervalo de verificação. O padrão verifica o HubSpot em intervalos fixos, o que introduz latência proporcional a esse intervalo. Se o seu caso de uso exigir sincronização em tempo real, essa configuração do módulo não vai suportá-la: a sincronização em tempo real exige um gatilho com base em Webhook e uma configuração de módulo do HubSpot totalmente diferente. ![make-hubspot-trigger-schedule-settings](__CODE_BLOCK_7__

Step 2: Configure the Salesforce connection

Add a Salesforce module to your Scenario using the[ ](__CODE_BLOCK_8__ For the action type, choose between two options: * Create a Record: creates a new Salesforce lead every time the module runs * Upsert a Record: checks for an existing record first using an external ID field, then creates or updates accordingly — this is the option that prevents duplicates at the write stage

To establish the connection, you'll need your Salesforce connected app credentials. In Salesforce, navigate to Setup, then App Manager, open your connected app, and copy the Consumer Key and Consumer Secret. Paste both into Make's Salesforce connection panel when prompted. One configuration error appears consistently at this stage: the environment selector. Make's Salesforce connection panel includes a toggle between sandbox and production. If you build and test against your sandbox but leave the toggle set to production, or vice versa, the connection will authenticate but write to the wrong org. Confirm the environment before running any test records. Your Salesforce API user account also needs the correct profile permissions: at minimum, API access enabled, and read/write permissions on the Lead or Contact object you're targeting. ![make-salesforce-connection-panel-upsert-record](__CODE_BLOCK_9__

Step 3: Map fields between HubSpot and Salesforce

Field mapping is where most HubSpot Salesforce data mapping problems originate. In the Salesforce module panel, use the bundle variable picker to select the HubSpot output property for each Salesforce destination field. The table below covers the most common mappings and where transformations are required: | HubSpot bundle variable | Salesforce lead field | Transformation needed | | --- | --- | --- | | {{1.firstname}} | FirstName | None | | {{1.lastname}} | LastName | None | | {{1.email}} | Email | None | | {{1.phone}} | Phone | toString({{1.phone}}) | | {{1.company}} | Company | None | | {{1.hs_lead_status}} | LeadSource | Os valores da lista suspensa devem corresponder exatamente ao Salesforce | | {{1.createdate}} | CreatedDate | formatDate({{1.createdate}}; "YYYY-MM-DD") | | {{1.hubspot_owner_id}} | OwnerId | Requer consulta separada de ID de usuário | Três campos causam erros de sincronização com mais frequência: campos de data, em que o HubSpot retorna um timestamp Unix e o Salesforce espera ISO 8601, exigindo formatDate; campos de lista suspensa, em que os valores devem corresponder exatamente a uma opção válida do Salesforce. Campos obrigatórios do Salesforce sem equivalente no HubSpot precisam de um valor padrão definido no módulo, ou o registro vai falhar em todas as execuções. ![Make scenario image for salesforce & Hubspot](__CODE_BLOCK_10__

Step 4: Add a deduplication filter

Before the Salesforce write module, add a Salesforce Search Records module to query by email address. If a matching record is found, the bundle returns a Salesforce lead ID. If not, it returns empty. Use that result to drive a[ ](__CODE_BLOCK_11__ with two branches: * New lead: search returns empty, route runs Salesforce Create a Record * Existing lead: search returns a matching ID, route runs Salesforce Upsert a Record

Without this logic, every HubSpot contact update triggers a new Salesforce lead record, polluting your CRM with duplicates that are difficult to reconcile after the fact. One tradeoff to account for: the Salesforce Search Records module consumes an Operation on every Scenario run. Mitigate it by tightening your trigger conditions in Step 1, so the Scenario only fires on contacts that are genuinely new or meaningfully updated, rather than on every minor property change.

Step 5: Handle errors and set up notifications

In a CRM sync context, silent failures are dangerous. A contact that fails to create in Salesforce simply disappears from the sales pipeline, with no visibility for anyone. Right-click the Salesforce Create a Record or Salesforce Upsert a Record module and select "Add error handler" to open the[ ](__CODE_BLOCK_12__ Choose the right directive for your use case: | Directive | When to use it | | --- | --- | | Break | Stores the failed bundle in Incomplete Executions for manual or automatic retry — the right default for a CRM write | | Resume | Continues the Scenario with a fallback value — use only if the failed record is non-critical | | Rollback | Stops execution and attempts to revert prior actions — use for multi-system writes where partial records cause bigger problems | After the error handler, add a notification module: a Slack message or email that fires on failure, with {{error.message}} and the contact ID mapped into the message body. This gives your team immediate visibility when a sync fails. Finally, enable email alerts for incomplete runs in your Scenario settings. This adds a second layer of monitoring that catches failures the error handler route itself may not surface.

Step 6: Test the Scenario and validate data

Click Run once in the Scenario Builder toolbar to trigger a single [test execution](__CODE_BLOCK_13__ Use a real HubSpot contact with a known email address so you can cross-reference the output directly in Salesforce. After the run, check each module's output bubble to confirm data passed through correctly. Then validate the resulting Salesforce record against the following checklist: * Record was created or updated, not duplicated * All mapped field values match the HubSpot source contact exactly * Data types are correct: dates in ISO 8601 format, phone numbers as strings * Record ownership transferred to the expected Salesforce user * The error handler route was not triggered

If any item fails, open the bundle output for the failing module in the Scenario Builder to identify where the data broke down. Fix the mapping or transformation, then rerun. Run five to ten test records before activating the Scenario for production use. A single passing test rarely surfaces edge cases around picklist values, missing required fields, or contacts with incomplete data.

What are common use cases for a HubSpot Salesforce integration?

Most ops and RevOps teams build a HubSpot Salesforce integration for one of two reasons: * Automating the marketing lead handoff to sales * Keeping deal stage data consistent across both platforms for revenue reporting

Both follow the same Scenario architecture covered in this guide, with different trigger conditions and field mappings. Start from Make's create a Salesforce lead from a HubSpot CRM [contact template](__CODE_BLOCK_14__ to accelerate either build. | Use case | Trigger | Outcome | | --- | --- | --- | | Marketing lead handoff | Contact reaches MQL status in HubSpot | Salesforce lead created and assigned to the correct rep within minutes | | Deal stage sync | Deal stage changes in Salesforce | HubSpot deal record updated to match, keeping attribution intact |

Marketing lead handoff to sales

When a contact reaches MQL status, the HubSpot Watch CRM Objects module triggers the Scenario and creates a Salesforce lead assigned to the correct sales rep based on territory mapping. The rep receives a fully populated lead record with HubSpot activity history attached, with no manual handoff required.

Deal stage synchronization for revenue reporting

When a deal stage changes in Salesforce, a Salesforce Watch Records module triggers a second Scenario that updates the corresponding HubSpot deal record. Attribution and forecasting data stays consistent across both platforms without manual reconciliation.

Best practices for a reliable HubSpot Salesforce integration

A HubSpot Salesforce integration handles live pipeline data. Configuration errors don't just create noise: they lose leads and corrupt revenue reporting. These three practices reduce that risk significantly. | Practice | What to do | What goes wrong if skipped | | --- | --- | --- | | Define your field mapping schema first | Document every HubSpot property, its Salesforce equivalent, data type, and transformation needed before opening Make. Flag required Salesforce fields with no HubSpot source: these need default values or the record hard-fails on every run. | Required fields with no source value cause failures on every run | | Use sandbox environments | Build and test in HubSpot's sandbox (Professional and Enterprise) e a organização de sandbox do Salesforce antes de conectar credenciais de produção. Teste com 50 a 100 registros, não apenas um. | Erros corrompem dados reais do CRM sem possibilidade de reversão limpa | | Controle versões e documente seus cenários | Use as anotações do cenário) da Make para anotar a lógica do roteador e as decisões de mapeamento de campos. Ao atualizar mapeamentos ou adicionar rotas, teste de forma isolada antes de ativar. | A lógica fica impossível de depurar ou repassar quando muda |

Onde ir a partir daqui

Agora você pode criar uma integração HubSpot Salesforce que lida com deduplicação, transformação de campos, alertas de erro e validação de sincronização: todo o conjunto de recursos que uma sincronização de CRM em nível de produção exige. O resultado é que as equipes de vendas e marketing passam a trabalhar com os mesmos dados de contatos e pipeline, sem exportações manuais nem reconciliação entre plataformas. A forma mais rápida de começar é a partir de um cenário pré-pronto, em vez de começar do zero. Navegue pelos templates) da Make para ver modelos prontos para uso que cobrem os padrões de sincronização mais comuns e, depois, adapte os mapeamentos de campos e a lógica de roteamento para se adequar à sua configuração específica. Crie uma conta gratuita no Make) e crie seu primeiro cenário hoje mesmo.

FAQs

1. Qual é a diferença entre o conector nativo do HubSpot para Salesforce e criar a integração no Make? O conector nativo do HubSpot lida com a sincronização de objetos padrão com uma configuração point-and-click e funciona bem para equipes com mapeamentos de campos simples. Ele não oferece suporte a lógica condicional, roteamento personalizado ou alertas de erro. Uma integração criada no Make oferece controle total sobre condições de sincronização, transformações de campos, lógica de deduplicação e tratamento de erros, sendo a melhor opção para equipes de RevOps com requisitos de dados mais complexos. 2. O Salesforce pode ser integrado ao HubSpot? Sim. Você pode conectar as duas plataformas usando o conector nativo do HubSpot para Salesforce ou criando uma integração personalizada no Make. O conector nativo é adequado para equipes com requisitos padrão de sincronização. O Make é adequado para equipes que precisam de lógica condicional, transformação de campos, deduplicação e tratamento de erros em toda a camada de integração. 3. Como evito registros duplicados ao sincronizar contatos do HubSpot com o Salesforce? Adicione um módulo Salesforce Search Records antes do módulo de gravação para consultar pelo endereço de e-mail. Passe o resultado para um roteador: se a busca retornar vazia, direcione para Salesforce Create a Record; se retornar uma correspondência, direcione para Salesforce Upsert a Record. Sem essa lógica, cada atualização de contato do HubSpot cria um novo registro de lead no Salesforce, independentemente de já existir um. 4. Quanto tempo leva para configurar essa integração e quantas Operations ela vai usar? Um cenário básico de seis módulos seguindo este guia leva de duas a quatro horas para ser criado e testado. Cada execução consome uma Operation por módulo executado, então uma execução completa usa seis Operations. Consulte os recursos) da Make para calcular seu uso mensal com base no volume de contatos e na frequência de verificação. 5. Posso fazer isso no Zapier em vez do Make? O Zapier oferece suporte a sincronizações básicas de HubSpot para Salesforce, mas usa uma estrutura linear de caminho único. Ele não oferece suporte a roteadores com vários ramos, o que significa que você não consegue tratar registros novos e existentes de forma diferente na mesma automação. O Scenario Builder do Make lida com roteamento condicional, funções de transformação de dados e tratadores de erro que a arquitetura do Zapier não suporta nativamente. 6. Como escalo essa integração à medida que o volume de dados cresce? Ajuste as condições do gatilho para que o cenário só seja acionado em mudanças significativas nos contatos, e não em toda atualização de propriedade. Use gatilhos com base em Webhook em vez de polling para sincronização em tempo real em grande volume. Separe tipos de objeto com alto tráfego em cenários distintos para isolar falhas e monitorar o desempenho de forma independente. Atualize seu plano do Make conforme o uso de Operations aumentar, em vez de deixar a fila do cenário acumular.