Make + HubSpot Workflows for RevOps: 4 Builds That Matter
On this page
HubSpot workflows are genuinely good at linear, single-object automation. Lifecycle stage changes, simple task creation, internal emails when a deal moves stages. But every RevOps practitioner I know hits the same wall within six months: the moment your logic needs to reach outside HubSpot, read from a spreadsheet, branch across two objects simultaneously, or call an endpoint that returns nested JSON, native workflows tap out. That is exactly where Make earns its seat in the stack.
Why Make Belongs in Your HubSpot Stack
HubSpot workflows execute one object at a time and can only branch on properties that already live inside HubSpot. That sounds obvious until you realize what it rules out. You cannot look up a rep’s current quota attainment in Salesforce before routing. You cannot check a Google Sheet for territory mappings. And you cannot parse a Clearbit or Clay webhook payload that returns deeply nested firmographic data and write it back to the right contact fields conditionally.
Make solves this by treating HubSpot as one node in a larger directed graph. Every scenario is a sequence of modules. Make passes a data bundle between them, you call an external API, transform the response with a built-in function, run a Router to branch on the result, and write back to HubSpot in the same execution. No code required, though you can drop JavaScript into a Tools module when the logic gets messy.
My strong opinion: stop trying to solve cross-object problems inside HubSpot’s workflow builder. You will end up with a Frankenstein of workaround properties and enrollment triggers that nobody can audit six months later. Build the external logic in Make where it belongs and keep HubSpot workflows for what they are actually good at.
Where teams get burned before the first scenario runs
The most common failure mode I see is scope misconfiguration on the HubSpot Private App. Make’s HubSpot modules require specific OAuth scopes, and if your Private App is missing crm.objects.contacts.write or sales-email-read, the scenario will authenticate fine and then fail silently on the first real record. Always create a dedicated Private App per environment (dev and prod) and audit scopes before you build anything.
Minimum scopes for the 4 workflows below:
crm.objects.contacts.read
crm.objects.contacts.write
crm.objects.deals.read
crm.objects.deals.write
crm.objects.owners.read
sales-email-read (sequence enrollment)
crm.schemas.contacts.read
timeline (activity logging)
The Four Builds
Workflow 1: Territory-Based Lead Routing
HubSpot can round-robin by owner. It cannot route based on data that lives outside HubSpot. I use this build whenever a client has territory maps maintained in Google Sheets or Airtable that need to drive owner assignment in real time. Round-robin is a cop-out for teams that haven’t done the work to define territories. Do the territory work first, then automate the routing.
In Make, add a HubSpot module set to 'Watch New Contacts'. Set the filter to only fire when Lead Source is not blank and Lifecycle Stage equals Lead. This avoids firing on manual imports with no source data.
Add a Google Sheets 'Search Rows' module. Pass the contact's State or Zip Code property. Your sheet has columns: Zip Prefix, Region, Owner Email, Owner HubSpot ID. Return the matching Owner HubSpot ID.
Add a Router with two branches. Branch 1 runs when the Sheets lookup returned a non-empty Owner HubSpot ID. Branch 2 catches unmapped territories and assigns to a round-robin fallback owner list you hard-code in a Set Variable module.
Map the Owner HubSpot ID from the Sheets lookup to the hubspot_owner_id field. Also set a custom property like Territory Routing Source to 'Make' so you can audit which contacts were auto-routed vs. manually assigned.
Post a Slack message to the rep's DM using their Slack ID (store this in your Sheets territory map alongside the HubSpot Owner ID). Include contact name, company, and a direct link to the HubSpot record using the contact ID in the URL.
n8n equivalent: Use the HubSpot Trigger node on Contact Created, a Google Sheets node with the Lookup operation, an IF node for the match branch, and a HubSpot node with the Update operation. The logic is identical. The interface is just node-based instead of module-based.
Workflow 2: Deal Tagging from Enrichment Webhooks
When Clay or Clearbit posts enrichment data to a webhook, HubSpot has no native way to parse the response and conditionally apply deal tags or custom properties. Make handles this cleanly, and it is honestly the build I recommend first to any team running outbound, because bad ICP scoring at the top of the funnel costs you far more than the Make subscription.
Create a custom webhook in Make. Paste the webhook URL into Clay as a webhook export destination or into Clearbit's enrichment webhook settings. Make will auto-detect the schema on first hit.
Use Make's built-in JSON parsing to pull employee count, industry, funding stage, and tech stack from the payload. Clay payloads are usually nested two levels deep. Map each to a named variable for cleaner downstream references.
Set up Router branches for your ICP tiers. Example: Branch A fires if employee count is between 50 and 500 AND funding stage is Series A or later. Branch B fires for everything else. Each branch sets a Deal Tag variable and an ICP Score variable.
Push the ICP Tier, ICP Score, and enrichment timestamp back to HubSpot as custom properties on the Contact or associated Deal. This makes the data available to native HubSpot workflows for downstream sequencing or rep tasks.
Workflow 3: Sequence Enrollment Triggers Based on External Signals
HubSpot can enroll contacts in sequences based on internal properties. It has no mechanism for external signals like G2 intent, Bombora surges, or product usage hitting a threshold. I have built this exact workflow for three SaaS clients in the past year, and in every case it cut the time between a signal firing and a rep following up from over 48 hours to under 10 minutes.
Bombora, G2 Buyer Intent, or your product database posts a webhook to Make when a target account hits a signal threshold (e.g. three intent surges in seven days, or a freemium account hits the usage limit).
Use HubSpot's Search API module in Make to find the matching contact by email or company domain from the webhook payload. Return the Contact ID and check the Active Sequence field to avoid double-enrollment.
Add a Make Filter (the lightning bolt between modules) that only continues if: Active Sequence is false, Lifecycle Stage is Lead or MQL, and the last sequence enrollment was more than 14 days ago. This prevents burning contacts with repeat triggers.
Use Make's HTTP module to POST to the HubSpot Sequences enrollment endpoint. Pass the contact ID, sequence ID, and the assigned owner's user ID. The contact must have an email and the owner must have a Sales Hub seat or enrollment will fail silently.
After enrollment, write a Timeline API event to the contact record documenting the trigger source, signal type, and enrollment timestamp. This is critical for attribution when marketing asks why a contact entered a sequence.
Per HubSpot’s Sequences API documentation, the enrolling user must have an assigned Sales Hub seat. Check this before you build. It is the single most common reason this workflow fails in QA.
Workflow 4: Slack-to-HubSpot Deal Feedback Loop
Reps leave deal intelligence in Slack, not in HubSpot. That is not laziness. It is a context-switching problem, and the solution is not to yell at reps to log their notes. The solution is to make Slack the data entry point.
Set up a Slack workflow that fires when a rep uses a message shortcut or types a slash command in your deal-room channel. The Slack workflow collects: Deal Name, Next Step, Competitor Mentioned, and Confidence Score via a form modal.
Use Make's Slack module to watch for workflow step submissions or incoming webhooks from Slack. Alternatively, have the Slack workflow POST directly to a Make webhook URL.
Use HubSpot Search Deals by name (partial match) and return the top result. If multiple matches exist, use the Iterator and Array Aggregator to pick the one with the most recent activity date.
Push the Next Step to the deal's Next Step property, update the Competitor field, set the new Confidence Score, and create a HubSpot Note on the deal with the full Slack text and the submitting rep's name. Set note timestamp to now.
Make vs. n8n for HubSpot Automation
For teams deciding whether to absorb Make’s operation costs or self-host n8n instead, the answer is mostly a function of infrastructure comfort and monthly volume. I default to Make for clients without an in-house engineer. For technical teams already running containerized workloads on Railway or Render, n8n self-hosted is effectively free and the HubSpot node coverage is solid enough to replicate every workflow in this post.
Make or n8n for HubSpot automation?
Choose Make if
- You want a RevOps generalist to own these workflows without an engineer on call
- Your monthly volume fits comfortably inside the Core or Pro operation tiers
- You value a managed runtime and the fastest path from idea to a working HubSpot automation
Choose n8n if
- You are comfortable running a container on Railway or Render and want effectively free execution
- Your workflows call custom code or internal APIs that low-code modules cannot reach
- Your volume is high enough that per-operation pricing would sting every month
The takeaway
Native HubSpot workflows are the right tool until your logic needs to leave HubSpot. The four builds above (lead routing on external data, cross-object deal tagging, sequence enrollment from product signals, and the Slack write-back loop) are where I see mid-market RevOps teams get the fastest payback. Start with lead routing. It is the highest-leverage build, it exercises every Make pattern the other three reuse, and a broken router is visible within a day, so you learn your error-handling muscles early.
Frequently asked questions
What can Make do with HubSpot that native workflows can't?
Make can branch logic across multiple apps simultaneously, handle webhook payloads with nested JSON, and write back to HubSpot based on data from external sources like Clearbit or Clay. Native HubSpot workflows are limited to HubSpot-owned data and a single linear execution path.
Is Make or n8n better for HubSpot automation?
Make is faster to configure for teams already using a visual builder, but n8n is self-hostable and free for most RevOps use cases if you have someone who can manage a cloud instance. Both have solid HubSpot modules.
How do I trigger a HubSpot sequence from Make?
Use the HubSpot module to enroll a contact via the Sequences API endpoint, passing the contact ID and sequence ID. You must use a Sales Hub Seat license and the contact must not already be active in a sequence.
Can Make handle HubSpot lead routing across territories?
Yes. Make can pull territory or account data from an external source like a Google Sheet or Salesforce, then use a Router module to assign HubSpot contact owner based on matching logic that HubSpot workflows cannot cross-reference externally.
What is the cost difference between Make and n8n for HubSpot workflows?
Make starts at around 9 USD per month for 10,000 operations. n8n is free if self-hosted, or starts at 20 USD per month on n8n Cloud. For low-to-mid volume RevOps automation, n8n self-hosted is effectively zero marginal cost.
Free Newsletter
Get weekly automation playbooks for RevOps teams. No fluff.
Join RevOps and GTM operators who get our best automation guides, tool reviews, and workflow templates, delivered every week.
No spam. Unsubscribe anytime.
Enjoying this? Share it with your team.
Some links are affiliate links. Disclosure.