How do I move a deal to the next stage automatically in HubSpot?
HubSpot has no advance to the next stage action. A workflow writes the stage with Set property value, so you decide the trigger yourself: a property change, a form submission, or a wait until event with an expiry. Sales Hub Professional covers all nine specs here. Budget 25 to 30 minutes for the first one. The trap is renaming a stage later, which breaks the branch silently and stops the automation without an error.
The 9 specs, in build order
Each spec states its minimum tier. Free ones open in full; the others show their public preview and the date their full spec lands.
What a spec looks like
Every spec follows the same nine sections, so a team reads one and knows how to read all of them.
- Outcome, when to use it and when not to
- Prerequisites: properties, lists, tiers, with the JSON to create them
- Enrollment and re-enrollment, then every step with its parameters
- Known pitfalls, a test plan, variants, and the YAML build spec
What breaks, and how the specs prevent it
Branch conditions hold the stage you picked when you built the workflow. Rename that stage in Settings and the condition stops matching, with no error and no warning. The deal simply falls through, the task never appears, and nobody notices until someone asks why the checklist stopped. Deleting a stage leaves the same dangling condition behind.
A branch compares a property to a value or to another property. It cannot tell that Negotiation sits after Demo, and it cannot compute a difference. That is why three of these specs maintain a Stage Order number and a snapshot property: direction of movement is detected by comparing two numbers you wrote yourself, and every valid skip pair has to be enumerated as its own branch.
There is no native action that completes the task from the stage a deal just left. It sits open in the rep queue until someone closes it by hand. Worse, re-enrollment on stage change means a deal that bounces back and forward regenerates the same checklist, with no dedupe against the task still open from last time.
What this bundle builds
Nine specs for the pipeline where deals move because someone remembered, not because the process moved them. The starting point is an honest one: HubSpot has no action called advance to the next stage. What you get is Set property value on Deal stage, and the whole job is deciding what should fire it and what should happen around it.
So the collection covers the four things teams actually ask for under the same question. Tasks that appear when a deal enters a stage, so a rep knows what this stage means. A timer that notices when the deal has not moved, with a nudge to the owner and an escalation to a manager. Properties that record how long the deal has been where it is, whether it went backward, and whether it skipped stages the reporting assumes it passed through. And the data the stage is supposed to capture: a probability for the forecast, a loss reason on Closed Lost.
It fits an in-house sales operations owner on Sales Hub Professional, and an agency rebuilding pipeline hygiene on a new portal. No custom code, no Operations Hub, no extra hub.
How the pieces fit together
Build the stage-entry tasks first. They are the cheapest to show a sales manager, and the conversation about what task belongs to which stage is 80 percent of the real work. The checklist spec extends the same branch structure once the single-task version is agreed.
The timers come second, and they depend on nothing but the stage itself. Each one needs its own guard property, a checkbox that stops a second nudge firing on the same visit to the stage.
The tracking specs come third because two of them share a number. Stage Order, the numeric stand-in for stage position, is written by the probability mapping and read by the regression check. The stage-skip spec uses the same documented stage order, in the text-snapshot form. Build the probability mapping before the regression alert or you will write the same stage list twice.
The loss reason spec is independent and can go in at any point.
What you get
- 9 specs, each with outcome, prerequisites, enrollment, steps, known pitfalls, a test plan and variants
- Each spec ships as PDF and Markdown
- Properties JSON, 13 properties on the deal object, including the guard checkboxes and the snapshot fields
- Workflow JSON for all 9, in Automation API format, switched off on import
- No custom coded actions in this collection, everything runs on native workflow actions
- A test plan per spec, including the backward stage move that proves the regression branch fires
- Install in one click for Full and Agency buyers
Who it is for, and who should skip it
This is for the person who owns the pipeline on Sales Hub Professional and is tired of pipeline review being an archaeology exercise. The stage-entry tasks and the stale deal alert pay for themselves in the first week.
Skip it if your pipeline has three stages and a small team, since a checklist workflow adds overhead where there is no process to hold. Skip it too if what you really need is the deal to advance when a task gets ticked. Those two specs are not written yet and this page will not pretend otherwise. If you want the same discipline on tickets rather than deals, the SLA and escalation bundle is the closer fit.
Questions admins ask
Can a workflow move a deal to the next stage when a task is completed?
Not with the nine specs on this page. They create tasks, they do not read task completion, and that gap is the single most asked version of this question. Two specs are being written for it, one for a single task and one for a full task set, and they will be added here when they are done. Until then the honest answer is that this collection times the stage move or nudges the owner, it does not consume a completed task.
How do I move a deal automatically after a set number of days in a stage?
Use the wait until event pattern. The workflow waits for the deal stage to stop being the target stage and expires after 14 days. If the deal advances first, the workflow exits and nobody is bothered. If the expiry hits, it sets a guard property, creates a task and notifies the owner, then waits another 7 days before escalating. A fixed delay plus a re-check branch does the same job if your editor does not expose the wait.
Why does my deal sit in a delay and never come out?
An event-based wait only watches the exact property named in its condition. If the deal is deleted or merged while it waits, the instance ends silently with no notification. A deal that leaves the stage and comes back restarts the wait from zero, which hides deals that are genuinely stuck across several short visits. Check the History tab rather than assuming the delay is still counting.
Can I stop a rep from marking a deal Closed Lost without a reason?
Not with a workflow. A workflow is reactive: it notices the blank field after the stage already changed, then chases it with a notification, a task and a manager escalation one business day later. The preventive control is the native required property rule on the stage itself, set in the pipeline editor. Use both, the rule to block and the workflow to chase what slips through.
Can I get a weighted forecast amount from these workflows?
No. Multiplying amount by probability is arithmetic between two properties, and workflow actions do not do that. You get the probability written onto the deal by stage, which feeds a report. For a true weighted amount, use the native Forecast tool, which already computes it at pipeline level, or a calculated property on Operations Hub.