Can HubSpot workflows call external APIs?

With custom code actions on higher tiers, yes, within limits. For anything beyond a simple call, the orchestrator is easier to build, test and monitor. Use HubSpot's custom code for small, HubSpot-centric logic and the orchestrator for integrations.

What happens when both systems try to update a deal?

Loops, overwrites and confusion. The ownership table prevents it: one writer per property. Where two systems must touch the same record, use a marker property so each can tell whose change it is reacting to.

How do we document which system owns what?

A one-page table of properties and events with the writing system beside each, kept with the workflow documentation and reviewed when either side changes. It is the simplest document in the stack and the one that prevents the most confusing bugs.

← Blog·Tools & how-tos

HubSpot workflows or an external orchestrator: where to build each automation

HubSpot's native workflows handle most CRM automation well; some things they cannot do at all. The rule for deciding what lives in HubSpot and what lives in n8n or Make, and how to keep the two from fighting.

22 Nov 2025 · 2 min read · by HeiSyn

Teams on HubSpot face the question with every new automation: build it as a HubSpot workflow, or in the orchestrator that already connects everything else? Both can do most things; the trouble comes from doing the same thing in both, or from building in the wrong place and hitting a limit six months later. A simple rule prevents most of it.

Build in HubSpot when the data is in HubSpot

Property-based branching, lifecycle stage changes, internal notifications, task creation, list membership, sequence enrolment, simple date-based delays. These are what workflows are for; they are visible to the team, they respect HubSpot's permissions, and they do not need a developer.

Build outside when the data is not

Anything that calls another system's API, transforms data in a way HubSpot's actions cannot, needs a loop, runs on a webhook from elsewhere, or requires logic that would need custom code. Enrichment, routing across systems, reconciliation, reporting extracts, agent integrations. The orchestrator calls HubSpot's API to read and write.

One owner per record change

Decide, for each property, which system may write it. Enrichment fields are written by the orchestrator; lifecycle stages by HubSpot workflows; deal stages by evidence events via the orchestrator. Two systems writing the same field produce loops and arguments. Write the ownership table down.

Make them cooperate

Use HubSpot's webhooks to trigger orchestrator flows on property changes rather than polling. Have orchestrator writes set a marker property so HubSpot workflows can react without re-triggering the orchestrator. Log every external write with a source. With this split, HubSpot stays the CRM everyone sees and the orchestrator stays the plumbing nobody has to.

Questions people ask next

Can HubSpot workflows call external APIs?: With custom code actions on higher tiers, yes, within limits. For anything beyond a simple call, the orchestrator is easier to build, test and monitor. Use HubSpot's custom code for small, HubSpot-centric logic and the orchestrator for integrations.
What happens when both systems try to update a deal?: Loops, overwrites and confusion. The ownership table prevents it: one writer per property. Where two systems must touch the same record, use a marker property so each can tell whose change it is reacting to.
How do we document which system owns what?: A one-page table of properties and events with the writing system beside each, kept with the workflow documentation and reviewed when either side changes. It is the simplest document in the stack and the one that prevents the most confusing bugs.

HubSpotn8narchitecture

Want this built for your team?

A free scoping call: we map your motion, name the number that should move, and quote a fixed-scope build.

blog/hubspot-workflows-vs-external-orchestration