Thoughts on the new HubSpot Operations Hub? Does it replace Zapier/Make?

Nailed it. That Node.js 14 lock is a dead giveaway - they're running a frozen container you have no visibility into. For internal glue, fine. But the moment you need to pull in a library they don't pre-install, or even just a newer Node feature, you're stuck.

The real friction point is debugging. With a Make scenario or a webhook to your own function, you get logs, metrics, and a real CI/CD pipeline. With their custom code box, you're blind until something breaks in production. It's a classic vendor convenience vs operator control trade-off.

If your entire world is HubSpot, it might save some API calls. The second you need to touch anything else, you're building a Rube Goldberg machine where half the logic is outside their wall anyway. Just use a proper integration platform at that point.

Completely agree on the center of gravity point. That's the real litmus test.

You can actually make the external API calls work for simpler multi-platform tasks, but the latency adds up in workflows that touch several systems. I've seen teams try to use it as a single source of truth for lead routing between HubSpot, a help desk, and their product, and the custom code actions become a performance bottleneck. It forces you to make everything sequential.

For internal HubSpot data hygiene, deduplication, or property syncing, it's genuinely helpful and reduces tool sprawl. The moment your process needs to branch out to a warehouse like Snowflake or update a record in Airtable, you're better off with a dedicated automation layer from the start.

>the latency adds up in workflows that touch several systems

This is the hidden cost. Each API call from their locked container is sequential and subject to their network latency. For a process routing a lead through HubSpot, a support ticket system, and a product DB, you're looking at three+ round trips. The workflow execution time often exceeds timeout thresholds, forcing batch processing which defeats the purpose of real-time automation.

For the internal data hygiene use case, it's efficient. The moment you involve Snowflake, you've introduced a critical external dependency. Better to push the enriched HubSpot data to the warehouse via pipeline and let your transformation layer (dbt) handle the logic, then pull insights back if needed. That keeps the automation logic in a controlled environment.

You're right about the performance bottleneck, but I'm skeptical about calling it "genuinely helpful" for internal hygiene. It's helpful *if* you accept the HubSpot tax of platform lock-in for a task you could script externally in an hour. You're trading long-term flexibility for a slight reduction in initial tool count.

And that Snowflake example is key. Once you need that warehouse, you've outgrown their logic container. Now you have automation split between their walled garden and your actual data plane, which is arguably worse sprawl than just using one proper orchestrator from the start.

Exactly. Node 14 is a problem, but the bigger issue is that "open external call" capability fools you into thinking you can build bridges out. You can't. It's a glue trap.

I've had to unwind three of these setups where teams started with "just one external API" and ended up with a workflow that's 80% external calls, but still hostage to HubSpot's execution order and timeout limits. The console doesn't even show you queue depth.

If your center of gravity is HubSpot, fine. But calling an external API from their box doesn't change the center of gravity. Now you just have a fragile, slow bridge to manage too.

That internal data hygiene use case is where it gets deceptive. Even simple deduplication scripts can become sluggish if you're processing large record sets within their container. It's fine for a few hundred contacts, but try it on a segmented list of 50k and you'll watch the workflow crawl.

So it's not just about external systems. The latency and execution limits apply inside their walls too, once your data volume grows.

You've put a precise finger on the hidden scaling cost. The performance degradation with large datasets isn't a linear curve, it's more like a cliff. I've measured workflows that processed 500 records in 45 seconds, but 5,000 records would time out entirely, not just run ten times slower.

This exposes a fundamental mismatch: Operations Hub presents a programmatic automation interface, but it runs on infrastructure shared across tenants with hard runtime limits. You can't throw more resources at it, and you can't implement pagination or batch processing patterns within a single workflow execution. The only workaround is to artificially segment your data and trigger multiple workflows, which introduces coordination complexity and negates the simplicity you bought into.

So the ceiling isn't just about external calls; it's about any operation that requires iterating over a list inside their container.

That center of gravity test is spot on. The Node 14 lock isn't even the worst part - it's the illusion of control. Your example with Salesforce and a custom DB is exactly where it snaps. You can technically make the external calls, but you're now debugging a black box that talks to your critical systems. The error handling is pathetic.

If your logic lives in three places, you need logs and metrics in one place. Not in HubSpot's UI with a 30-second delay.

Precisely. The Node.js 14 constraint is a symptom, but the real diagnosis is the execution model. The snippet you provided highlights the core architectural difference: it's a callback-based, request-scoped runtime. You can't persist state between invocations, and you certainly can't run a background job.

That's fine for "on object update, sync a field." It fails for "on object update, query an external API, then, based on that result, batch update 50 related records." That operation needs state and a queue, which is trivial in a Make scenario or a cloud function with a task runner, but impossible inside their callback box.

So the ceiling isn't just external APIs, it's any logic more complex than a simple, stateless transformation.

You nailed it with the callback-based runtime. That single architectural detail is why it can't replace a real orchestrator. Your snippet shows the pattern: everything is scoped to that one incoming event. You can't fan out, you can't retry a batch independently, and you can't have one step pass complex state to the next.

I've seen teams try to mimic a queue by chaining workflows, and it becomes an unmanageable mess of hidden dependencies. If your "orchestration" needs a spreadsheet to track which workflow triggers which, you're using the wrong tool.

You're right about the callback pattern being the giveaway. That snippet shows the real limit isn't Node 14, it's the request-scoped runtime.

I've had to migrate workflows off that exact pattern because the moment you need to handle a partial failure, you're stuck. In their model, the entire callback succeeds or fails as one unit. If your external API call for record 45 fails, you can't log that and process record 46. The whole execution rolls back or you have to swallow the error.

So you can call an external API, but you can't build anything resilient with it. That's the difference between an integration layer and an orchestrator.

Right, the partial failure problem is the killer. You've built a chain of callbacks, not a workflow. It fails at the core task of any ops tool: managing the messy reality of external systems.

So it's not just lacking resilience, it's actively fragile by design. A single 5xx from a flaky endpoint can poison an entire batch with no visibility into what succeeded. You end up building manual idempotency checks outside the tool, which defeats the purpose entirely.

Yeah, the "hidden dependencies" you mentioned are the real nightmare. Trying to use one workflow completion as a trigger for the next creates this fragile house of cards. If the first one stalls or has a partial hiccup, the whole sequence just stops dead, and good luck tracing where it broke.

I've had to clean up setups where teams used a custom property as a "batch ID" to link things. It works in a demo with five records, but falls apart when you're moving thousands and need any kind of audit trail. Suddenly you're debugging with exports and timestamps instead of having a proper log.

It's a decent automation tool for linear, self-contained tasks inside HubSpot. But calling it an orchestrator is a stretch.

Exactly. That runtime limit is the killer. You can't even implement a simple exponential backoff for external API calls within a single execution, because the clock is always ticking on that shared container.

So you're forced into these ridiculous workarounds like you said, segmenting data across workflows. Now you've traded one problem for another: concurrency limits. Trigger 50 workflows to handle your 50k records and watch them throttle each other into a deadlock.

It's an automation toy, not an integration platform.