Why Your Second HubSpot Automation Never Fires (And How to Fix It)

You build two workflows. The first one creates a deal when a form is submitted. The second one triggers when a deal is created — it sends a Slack notification, creates a task, assigns a rep.

You test the form. The deal gets created. The second workflow never fires.

You check the enrollment history. Nothing. You check the trigger conditions. They match. You re-publish both workflows. Nothing.

This will cost you 2-4 hours of debugging before you find the one sentence in HubSpot's documentation that explains it:

"Objects created from HubSpot Automations will not trigger other HubSpot Automations."

That's it. That's the entire explanation. It's not a bug. It's intentional. HubSpot built this to prevent infinite automation loops — if Workflow A creates an object that triggers Workflow B, which creates an object that triggers Workflow A, you get an infinite chain.

Their solution: kill the chain entirely. Anything created by an automation is invisible to other automations.

Where this actually bites people

The handoff workflow. Deal closes → Workflow 1 creates a task → Workflow 2 should trigger on task creation to notify the delivery team. Workflow 2 never fires.

The multi-pipeline setup. Lead qualifies → Workflow 1 creates a deal in Pipeline A → Workflow 2 should trigger on deal creation in Pipeline A to assign the right owner. Workflow 2 never fires.

The ClickUp integration. HubSpot workflow changes a deal property → ClickUp automation should trigger on that property change → ClickUp side doesn't see it because the property change came from an automation, and depending on how the integration handles it, the signal can get swallowed.

Every single one of these looks like a bug when you're debugging. The trigger conditions match. The workflow is active. There's no error message. It just doesn't fire.

The workarounds that actually work

1. Combine into a single workflow

Instead of Workflow A creating a deal and Workflow B triggering on deal creation — put both sets of actions in Workflow A.

Workflow A: Form submitted → Create deal → Wait 1 minute → Send Slack notification → Create task → Assign rep.

The downside: your workflows get long and harder to maintain. But it works reliably.

2. Use a delay + property-based trigger

Instead of triggering Workflow B on "object created," trigger it on a property change that Workflow A sets.

Example: Workflow A creates the deal AND sets a custom property automation_source = "form_submission". Workflow B triggers when automation_source is set to "form_submission".

Wait — does this actually work? Sometimes. The behavior is inconsistent depending on whether the property is set during creation or updated after. Test thoroughly.

3. Use external middleware

If you need reliable chaining — use an external tool (Zapier, Make, or a custom webhook) to listen for the object creation and trigger the next step from outside HubSpot.

This bypasses HubSpot's chain prevention entirely because the second trigger comes from an external system, not from a HubSpot automation.

The irony: you're adding a third tool to work around a limitation in the first tool. But it works.

4. Use Operations Hub (if you have it)

Operations Hub Professional ($800/mo) includes custom code actions in workflows. You can write JavaScript that runs within a workflow and directly calls the HubSpot API to create objects — and those API-created objects DO trigger other workflows.

Expensive solution. But if you're already on Operations Hub, it's the cleanest workaround.

The deeper problem

This chain prevention is a blunt instrument. It prevents loops — great. But it also prevents every legitimate multi-step automation pattern.

There's no allowlist. No "I know these two workflows are safe to chain." No "allow once" flag. It's all or nothing.

The HubSpot Ideas Forum has multiple threads requesting configurable chain behavior. As of April 2026, no movement on this.

What to actually do

Before you build a multi-workflow system in HubSpot, map out the dependency chain on paper. If Workflow B depends on an object that Workflow A creates — you already know it won't work. Restructure before you build.

The safest pattern: one workflow per trigger event. Put all downstream actions in the same workflow. If that makes the workflow too complex, use delays and branches — not separate workflows.