How do I move a deal to the next stage automatically in HubSpot?
Short answer
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.
Read the whole answerShow less
What a spec looks like
The nine sections, and the files
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
PDF, Markdown, properties JSON, workflow JSON, custom code where used. Test plan and known pitfalls in every spec.
Each spec states its minimum tier. The 12 free ones open in full, the others show their public preview.
The 9 specs, in build order
The stage change as a trigger
A deal entering a stage fires the tasks and the checklist that stage is supposed to produce.
What each spec doesHide
Moving the deal on time, or nudging whoever should
An event-based wait with a 14 day expiry, plus the activity-based alert for deals nobody touched.
What each spec doesHide
Knowing how long, and in which direction
One date property per deal for time in the current stage, plus regression and stage-skip detection.
What each spec doesHide
What the stage writes on the deal
Probability by stage for the forecast, and a loss reason that does not stay blank on Closed Lost.
What each spec doesHide
The 3 things that break this, and how the specs stop them
Renaming a stage breaks every branch that names 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.
How the specs stop itShow less
Workflows cannot rank stages or subtract numbers
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.
How the specs stop itShow less
The previous stage task stays open forever
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.
How the specs stop itShow less
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 Data Hub, no extra hub.
Read the restShow less
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 Data Hub.
Read 12 complete specs before you pay.
One per category, same format as the paid ones. Email only, no card.
We email the link, then a short note when specs change. Nothing else.
Here it is. Download the pack now (.zip) The link is in your inbox too.
Browse the library