Flagging stalled deals in HubSpot automatically comes down to two clocks and one workflow. The activity clock is the deal's Last activity date. The stage clock is how long the deal has sat in its current stage. Most teams build their stale-deal workflow on one clock, pick the wrong property for it, and then wonder why the workflow never fires. This guide is the HubSpot mechanics: which properties exist, which ones actually enroll deals, how to set thresholds per stage, what the workflow should do at each escalation, and the pipeline rules that stop reps hiding rot by moving deals around.
Trigger on Time in current stage and Last activity date together, never on Cumulative or Latest time in stage, and let the workflow write a Pipeline health property that views and managers read.
HubSpot's own documentation says deals will not enroll on the Cumulative time and Latest time in stage properties while they are in that stage. Use Time in current stage or Date entered current stage as the trigger, combine it with Last activity date, and escalate in steps: task to the rep, notification to the manager, then a parked stage. Never let automation close a deal.
If you want the strategy side, what a stale deal costs and how stage design causes most of them, that lives in our guide to stale deals in your sales pipeline. This page is the build.
Which HubSpot properties tell you a deal is stalling?
Six, and they split into two clocks. HubSpot documents all of them in its stage calculated properties and default deal properties articles.
The activity clock. Last activity date is, in HubSpot's words, "the most recent already past date and time a note, call, tracked and logged sales email, meeting, LinkedIn/SMS/WhatsApp message, or chat was logged on the deal record. It also includes completed tasks." Two things follow from that definition. Moving a deal to a new stage does not update it, so a rep who drags a deal forward has not made it look active. And it is set by HubSpot, so nobody can edit it to make a deal look alive.
The stage clock. Date entered current stage and Time in current stage are available on every tier and update whenever the deal moves. Professional and Enterprise portals also get four per-stage properties: Date entered [stage], Date exited [stage], Latest time in [stage] and Cumulative time in [stage]. These are the ones reporting loves and workflows cannot use in the obvious way, which the next section covers.
The property to avoid is Last modified date. HubSpot defines it as "the most recent date that any property on a deal was updated, regardless of the source (e.g., workflow, API)." A workflow that stamps a deal as stale updates Last modified date, which makes the deal look touched, which is the opposite of what you wanted.
Why does the obvious stalled-deal workflow never fire?
Because it is built on Cumulative time in stage or Latest time in stage, and those properties do not enroll deals that are still in the stage. HubSpot's documentation states it directly: "records won't be enrolled in workflows based on the Cumulative time and Latest time in [stage] properties if the record is currently in that stage." The fix, in the same article, is to trigger on Date entered current stage or Time in current stage instead.
This is the single most common reason a stale-deal workflow exists in a portal, has been on for a year, and has never enrolled anything. The workflow looks correct. The per-stage properties are the ones you see in reports, so they feel like the right choice. They are the right choice for reports and the wrong one for enrollment.
There is a second, quieter failure on the activity clock. Re-enrollment on a relative date condition such as "Last activity date is more than 21 days ago" only happens when the criteria is true at the moment the property changes, per HubSpot's re-enrollment triggers article. Last activity date changes when activity is logged, which is exactly when the deal is no longer stale, so re-enrollment on that property alone rarely re-catches a deal that went quiet a second time. The pattern below is built to survive both traps.
How do you build the workflow that actually flags rotting deals?
One deal-based workflow per pipeline, with branches per stage. The enrollment trigger combines both clocks and excludes closed stages.
The Pipeline health property is the piece most teams skip and the one that makes everything else usable. It is a single dropdown, Healthy, Stalling, Stalled, Rotting, written only by workflows. Views filter on it, the manager's board is built on it, and the reset workflow clears it the moment a rep logs anything. That reset is what solves the re-enrollment problem: you are not asking HubSpot to re-catch a deal on a relative date, you are letting the main workflow catch it fresh because its Time in current stage keeps climbing and the deal is still open.
Two build notes. Use "Time in current stage is greater than" rather than "Date entered current stage is before", because the first recalculates as time passes and the second is a fixed date that only changes on a stage move. And put the closed and Parked stages in the exclusion list explicitly, because a parked deal that re-enrolls will loop.
How do you set the stalling threshold for each stage?
From your own won deals, per stage, and label it as an assumption until a quarter of data confirms it. There is no universal number, and any guide that gives you one is guessing about your sales cycle.
The method we use: build a report of Cumulative time in [stage] for deals closed won in the last two or three quarters, take the median per stage, and set the stalling threshold at roughly one and a half times that median. A stage where won deals typically sit for eight days gets a twelve-day flag. A contract stage where won deals sit for twenty days gets thirty. Discovery might get a shorter clock than Negotiation, or a longer one, depending on how your buyers behave, and the report tells you which.
Then the escalation ladder scales off the same number: rep task at the threshold, manager at about twice it, parked at about three times. Write the three numbers per stage into a table in your RevOps documentation, because the workflow will need editing when the sales cycle changes and nobody will remember why the numbers are what they are.
What should happen at each escalation step?
Something a person can act on, and nothing a person would resent. The ladder above has three rungs, and the actions differ at each.
Rep task, at the threshold. A task, not just a notification, because tasks have due dates and show up in the rep's queue. The task title should carry the facts: stage, days since last activity, and the one question that matters, is this deal alive. Pair it with an internal notification so it is seen the same day. If the team lives in Slack, HubSpot's Slack integration can deliver the same notification there.
Manager notification, at roughly double the threshold. The manager gets a notification, the deal gets the Stalled value, and it appears on the Stalled view before the pipeline review. This is the rung where most of the value lives: the pipeline review stops being a walk through every deal and becomes a walk through the flagged ones. Our guide to running the pipeline review meeting assumes this view exists.
Park, at roughly triple. The deal moves to a Parked stage with zero probability so it leaves the forecast, and Pipeline health reads Rotting. It does not move to Closed lost. Some teams do auto-close with a "no buyer response" reason and that is defensible, but a parked stage keeps the deal's history intact, keeps the contact associations from being orphaned, and leaves the closed-lost decision with a human who can pick a real reason. Rotating the deal to a new owner is another option at this rung, and HubSpot workflows can do it, but only do that where the ownership rule says the deal was assigned wrong in the first place. Rotation as punishment produces reps who log fake activity.
Which pipeline rules stop reps hiding a rotting deal?
Three, and they are on by default in none of the portals we see. HubSpot's pipeline rules article lists them. All three need Professional or Enterprise.
Restrict moving backwards. Once a deal passes a stage you select, it cannot be moved back before it. This closes the oldest trick in pipeline hygiene: dragging a stalled Proposal deal back to Discovery to reset its stage clock. With the rule on, the clock is honest.
Restrict skipping stages. A deal cannot jump from Discovery to Contract sent. Deals can still go straight to a closed stage, which HubSpot allows regardless. This matters for the thresholds, because Cumulative time in [stage] reports only work when deals actually pass through the stages.
Limit which stages deals can be created in. New deals land in the stage you designate, through the interface, integrations and the API. Without this, deals created by an integration in a late stage inherit a fresh stage clock and skip the early thresholds entirely.
Enterprise portals can add an approval step at a chosen stage, which HubSpot notes "cannot be bypassed" by any user. That is a different problem, deal desk control rather than pipeline rot, and it is covered in our sales pipeline stages guide.
Which views and reports make the flags visible?
Three views and one report, all filtered on the Pipeline health property the workflow writes.
- Stalling, mine. Pipeline health is Stalling, deal owner is me. The rep's morning list.
- Stalled and Rotting, team. Pipeline health is any of Stalled, Rotting, grouped by owner. The manager's pipeline review view.
- Parked. Deal stage is Parked, sorted by amount. The quarterly cleanup list, where closed-lost decisions get made in a batch.
- Time in stage report. A custom deal report on Cumulative time in [stage] by stage for closed won deals, refreshed quarterly. This is where the thresholds come from and where you find out they have drifted.
Put Pipeline health on the deal board card too. A rep who sees Stalling on the card before the task arrives usually fixes it before the task arrives.
How does this connect to forecasting and deal stage design?
The flag is only as good as the stages underneath it. A pipeline where Proposal sent means five different things to five reps will produce thresholds that mean nothing, which is why the stage definitions in our guide to HubSpot deal stages come first. Once the stages are honest, the Parked stage does the forecasting work automatically: anything rotting leaves the weighted pipeline without anyone editing a probability, which is most of what makes a forecast accurate in HubSpot.
If your pipeline needs the stages rebuilt before any of this can run, that is what our HubSpot migration and architecture service does, and the stalled-deal workflow is one of the first things we switch on afterwards.
FAQ
Which property should trigger a stalled-deal workflow in HubSpot?
Time in current stage combined with Last activity date, with closed and parked stages excluded. Do not trigger on Cumulative time in stage or Latest time in stage, because HubSpot documents that deals still in that stage will not enroll on them.
Does moving a deal to a new stage update Last activity date?
No. Last activity date only changes when a note, call, logged email, meeting, message, chat or completed task is logged on the deal. A stage move updates Date entered current stage and resets Time in current stage, which is why the two clocks are used together.
Why is Last modified date the wrong property for stale deals?
Because it updates whenever any property changes from any source, including workflows and the API. The workflow that flags a deal as stale would update Last modified date and make the deal look active.
How many days before a deal counts as stalled?
It depends on the stage and your sales cycle. Derive it from the median Cumulative time in stage of your closed won deals, roughly one and a half times that median per stage, and treat the number as an assumption until a quarter of data confirms it.
Should the workflow close rotting deals as lost automatically?
We recommend a Parked stage at zero probability instead. It removes the deal from the forecast, keeps its history and associations intact, and leaves the closed-lost reason to a person. Auto-closing with a no-response reason is a defensible alternative for high-volume pipelines.
What subscription do the stage time properties and pipeline rules need?
Time in current stage and Date entered current stage are on every tier. The per-stage Date entered, Date exited, Latest time and Cumulative time properties, and the pipeline rules for skipping, backward moves and creation stages, need Professional or Enterprise. The deal approval rule is Enterprise only.