# Salesforce Flow for managers: one automation that nudges stale opportunities https://salesbond.app/blog/salesforce-flow-stale-opportunity-task/ Published: 2026-10-08 · Updated: 2026-10-26 In Salesforce, a record-triggered flow fires when something on a record changes, so it cannot notice a stale opportunity, a deal that has gone quiet: nothing changed, and that is the whole problem. Use a scheduled flow (or a scheduled path) instead, which once a night finds open opportunities with no recent activity and creates a task for the owner. For a small team that is the one automation worth building first, and for a lot of teams it is the only one worth building at all. ## One automation is enough Most lists of Salesforce automation tools read like a catalogue: Workflow Rules, Process Builder, Flow, Apex, then twenty ideas for what to automate with them. A manager of six reps does not need the catalogue. They need the one thing their pipeline loses money on, and in our experience that thing is silence. An opportunity sits at Proposal for three weeks, nobody touched it, nobody noticed, and by the time it comes up in a pipeline review the buyer has signed with someone else or stopped answering. We think a manager should build exactly one automation before anything else, and it should be about silence. Not stage changes, not field updates, not a welcome email to a new lead. Those have an owner already: the rep who moved the stage is right there and knows it happened. Silence has no owner. It is the absence of an event, and the people who could act on it are the people who are not looking. We won’t spend a section on tool choice. Guides written for sales teams now point new automation at Flow rather than Process Builder ( [OctaveHQ: Salesforce Flow for sales teams](https://www.octavehq.com/post/salesforce-flow-sales-teams-automation-guide)), Apex is for developers, and Flow is what a manager or an admin can own. If Workflow Rules or Process Builder processes are still running in your org, [audit what those old rules still write to your opportunities](https://salesbond.app/blog/salesforce-automation-audit-workflow-rules-process-builder-flows/) before the new flow goes live. There is a second reason to stop at one. Every automation you add is something a rep learns to satisfy. A stage-exit validation gets a placeholder value. A required field gets “TBD”. The silence rule is harder to game, because the only way to make the task stop appearing is to do something on the opportunity, and we would rather have one rule reps respect then six they route around. The line between [what to automate and what to leave to people](https://salesbond.app/blog/what-not-to-automate-sales-process/) runs right here: the flow notices, a person decides. ## Record-triggered or scheduled flow? A record-triggered flow starts when a record is created, updated or deleted. A quiet opportunity does none of those things. That is why the first draft of this automation, the one almost everyone builds first, never fires: it waits for an update to an opportunity whose problem is that it is not being updated. There are two ways around that, and they are the two the Trailhead community points to for this exact question ( [Trailblazer Community: flow for opportunities with no activity](https://trailhead.salesforce.com/trailblazer-community/feed/0D54S00000HDL4ASAX)). The first is a scheduled flow, listed in Flow Builder as a Schedule-Triggered Flow. It runs on a timetable, every night at a time you choose, with no record involved at the start. It asks one question of the whole pipeline: which open opportunities have been quiet for longer than N days? Then it does something with each answer. The second is a scheduled path on a record-triggered flow. The flow fires when the opportunity changes, and the scheduled path waits a set number of days after a date on the record before acting. It can work. For silence we prefer the scheduled flow, for one reason: a manager can explain it in a sentence. “Every night it looks for quiet deals.” A scheduled path has a start condition, a wait and a check at the end of the wait, and when it misfires you have to work out which of the three went wrong. ![Record-triggered flow never fires on a quiet opportunity, while a nightly scheduled flow finds it and creates a task](https://salesbond.app/wp-content/uploads/2026/10/salesforce-flow-stale-opportunity-task-2.png) ## The rule in plain words Say it out loud before you open Flow Builder. If you cannot say it, you will not be able to debug it: Every open opportunity that has had no activity for N days gets a task for its owner, due tomorrow, with the opportunity’s name in the subject. That is three decisions, and each one has a wrong answer that looks fine. “Open” means IsClosed is false. Not “stage is not Closed Won”, because then your Closed Lost deals come back every night as zombies. A published example of the filter uses exactly this shape: IsClosed equals false, LastActivityDate earlier than today minus 14, create a task for the owner ( [Revenue.io: Salesforce automation ideas](https://www.revenue.io/blog/salesforce-automation-ideas-that-save-sales-reps-hours-every-week); a blog example, not an official Salesforce recommendation). Fourteen is a fine first value. We will argue about it by stage further down. “A task for its owner” means the OwnerId of the opportunity, not the admin who built the flow and not the manager. The point is to put the quiet deal in front of the person who can call the customer. The manager sees it a different way: in a report of open tasks with the subject the flow writes, which doubles as a list of quiet deals without a separate dashboard. “Due tomorrow” is a position, not a technicality. A task due in a week is a task that gets snoozed. The deal has already been quiet for two weeks; the nudge should not add a third. Two guard rails the plain-words version hides. First, the flow has to check whether it already created this task, or a rep wakes up to fourteen identical tasks on one opportunity. The simplest guard is to look for an open task on the opportunity with the same subject before creating one. Second, keep the subject boring and searchable, something like “Quiet for 21 days: Harlow Freight”. It’s the only part of the task a rep reads before deciding whether to open it. The rule does not move the stage, change the close date or email the customer. It creates a to-do. If you have read our take on [one open task per opportunity](https://salesbond.app/blog/salesforce-tasks-next-step-rule/), you will recognise what the flow is really doing: inserting the next step the rep forgot to schedule, and showing the manager the gap at the same time. ## The trap: what counts as activity Here is where most versions of this flow quietly lie to the manager who built them. The filter leans on LastActivityDate, and the last activity date does not mean what the name suggests. It is driven by activity records: it moves when a task is closed or an event has happened, and an open task scheduled for next week does not move it. We went through that mechanic in the article above, and it cuts both ways for this flow. A rep who logs a call every Monday with “no answer, try again” has an opportunity that looks alive to the flow, because every logged call is a completed task and completed tasks move the date. Meanwhile a rep who booked a real meeting for next Thursday and did nothing else looks quiet, because the booked meeting has not happened yet. Then there are the deals with no activity at all. On an opportunity where nobody ever logged anything, LastActivityDate is simply empty, and depending on how you build the filter, “older than N days” may skip it. Those are the quietest deals in the pipeline. Before you trust the flow, find one such opportunity in your own org and check that it gets a task. If it doesn’t, add a second condition: LastActivityDate is empty and CreatedDate is older than N days. So the flow catches silence in the CRM, not silence with the customer. Those overlap most of the time. They are not the same thing, and the flow will produce a few tasks that are plain wrong in both directions. We accept that, because the alternative is no flow at all; what we do not accept is a manager reading the task list as if it were truth. The second part of the trap may be bigger, and it is specific to Salesforce. If your reps’ email is synced through Einstein Activity Capture, vendor guides report that the emails and meetings it captures are not stored as standard Task and Event records, which would limit what reports and Flow can see ( [Nektar: Salesforce email integration guide](https://nektar.ai/salesforce-email-integration-email-sync-complete-guide/)). That depends on how EAC is set up, so test it in your own org rather than taking our word for it. If it holds there, a rep who exchanged eight emails with the buyer this week, all visible on the opportunity timeline, can still look quiet to a flow that filters on LastActivityDate. The flow isn’t broken. It is looking at a different table. What we tell managers to do about it, in order of how much it costs: - Run the flow for two weeks and read every task it creates against the the timeline before you change anything. You will learn fast which pattern your org has. - If EAC causes most of the false alarms, make “log the call or email as a task” the team habit for anything that counts as real contact. It is a habit, not a setting, and the one-open-task rule needs it anyway. - If you cannot get there, the flow still catches the deals with no email traffic at all, which are usually the worst ones. That alone is worth running it for. ![Two columns of what LastActivityDate sees (completed tasks, past events) and misses (open tasks, EAC emails, future meetings)](https://salesbond.app/wp-content/uploads/2026/10/salesforce-flow-stale-opportunity-task-3.png) ## Thresholds by stage Shorten the threshold as the stage gets later, because the normal gap between touches shrinks as a deal gets closer to a decision. Fourteen days is the number in the published example and the one we would start with on a single filter. The numbers below are our recommendation, starting defaults rather than sourced facts; change them after you have watched your own pipeline for a month: - Early stages (qualification, discovery): 14 days. Buyers are slow here and a nudge every week is noise. - Proposal sent: 7 days. A proposal nobody has discussed in a week is already cooling. - Negotiation or verbal yes: 3 to 5 days. At this point a quiet deal is either closing or dying, and either way the rep should know which. In Flow terms that is one scheduled flow with a decision element on StageName rather than three flows, so the task subject and the duplicate guard live in one place. We would not build per-stage thresholds on day one, though. Start with one number, let it run, and split it only when the early-stage tasks turn out to be the ones reps ignore. If reps ignore all of them, the threshold is not the problem; see the section above. If you are tightening stage definitions at the same time, [exit criteria per stage](https://salesbond.app/blog/salesforce-opportunity-stage-exit-criteria/) is the companion rule: one says what a stage means, this one says how long it may stay quiet. ## What the task is for The flow is finished when the first task lands in a rep’s list. The rule isn’t finished until the manager has decided what happens next, and that is the part nobody automates. A task that says “Quiet for 21 days: Harlow Freight” is a question, not an instruction. The rep might answer it with a call, with a note that the buyer is on leave until the 20th, or with Closed Lost and a reason. All three are good answers. Marking the task complete and moving on is not, and you should expect to see exactly that in week one, because a completed task is the cheapest way to make the flow stop asking. It also moves LastActivityDate, so the opportunity goes quiet for another N days with nothing having happened. Watch for the opportunities whose only activity is the flow’s own tasks being closed. That list is short and it is the list for the next 1:1. The flow only notices; [sales coaching in Salesforce](https://salesbond.app/blog/sales-coaching-salesforce/) still needs a manager reading the Opportunity. A disclosure, since this is where a manager wonders whether to build this or buy it: we build SalesBond, a sales management layer on top of the CRM a team already uses; we started with Pipedrive, where the built-in [rotting feature](https://salesbond.app/blog/pipedrive-rotting-deals/) does a similar job with its own blind spots. Deal Health checks every deal in the connected CRM against more than 20 rules, activity gaps among them, and explains what is wrong with each one, so you get this check and others like it without building a flow. [Check your CRM with SalesBond](https://salesbond.app/) if that sounds like the week you would rather skip. Either way, the call on [whether a quiet deal is stalled or dead](https://salesbond.app/blog/stalled-deals-vs-dead-deals/) stays with a person. The flow, or the tool, has done its job the moment it puts the right deal in front of the right one.