Salesforce Pipeline Hygiene: 7 Checks to Automate

Salesforce pipeline hygiene is treated as a discipline problem. A manager opens the pipeline report on Monday, scrolls to the deals with close dates from last month, and spends the first twenty minutes of the review asking people to update their records. The reps promise to. Next Monday it happens again.

My position: that meeting is doing a machine’s job. Every hygiene question a manager asks out loud is a rule that can be written down, and a rule that can be written down can run every night without anyone asking. The pipeline review should be about deals. Right now, in most orgs, it’s about data.

Here are seven checks worth automating, ordered roughly from smallest build to largest. None of them is a project. Each is an afternoon of work that never gets scheduled because no single one is painful enough to win a slot in the queue.

1. Open deals with a close date in the past

This is the one everybody knows and almost nobody automates. An opportunity is still open, the close date was three weeks ago, and it’s sitting in a forecast it has no business being in.

The check is trivial: open opportunity, close date earlier than today. The build is what you do about it. Notify the owner the morning it expires. If it’s still expired after a few days, tell their manager. Put a visible flag on the record so it shows up in list views and reports.

What I would not build is the thing people ask for first, which is automatically pushing the date to the end of the month. That makes the report look clean and removes the only signal you had. Flag it, don’t fix it.

2. Deals that have stopped moving

A deal that has been in Proposal for ninety days isn’t in Proposal. It’s dead or it’s stuck, and either way the stage is lying to the forecast.

Salesforce already keeps the raw material. The OpportunityHistory object records the stage history of every opportunity without any setup, and the standard Opportunity History report built on it can show how long deals spent in each stage. What you don’t get out of the box is a rule of your own on top of it.

So build one. Stamp the date a deal entered its current stage, compute days in stage, and compare that against a limit you set per stage, because two weeks in Discovery and two weeks in Contract Sent mean very different things. Past the limit, the deal gets flagged as stalled. That one field turns “which of these are real?” from a conversation into a filter.

3. Close dates that keep sliding

One push is a deal that slipped. Four pushes is a deal that was never going to close when the rep said it would, and the pattern matters more than the current date.

Pipeline Inspection helps here if you have it turned on: Salesforce’s own training material describes it as highlighting recent changes to amounts, close dates, stages and forecast categories. That’s useful in the moment. It isn’t a number you can report on next quarter.

The build is a push counter: a field that goes up by one each time the close date moves into a later month. It’s small enough that a record-triggered flow can handle it, and I’d say so plainly; not every item on this list needs code. Once the counter exists you can sort by it, alert past a threshold, and finally answer which reps and which stages produce the slippage.

4. Open deals with nothing scheduled

The standard Last Activity field tells you what happened. Hygiene asks a different question: what happens next, and when?

An open opportunity with no future task or event is a deal nobody has committed to touching again. That’s the check. For every open deal, is there at least one open activity dated in the future? If not, flag it and tell the owner.

This is the one reps tend to appreciate, because it reads as a reminder rather than a reprimand. It’s also a place where logging friction shows up fast. If activity capture is spotty in your org, this check will be noisy until it isn’t, and that’s worth knowing too. It’s a big part of why reps don’t use Salesforce in the first place.

5. Stage gates that check real things

Most orgs already have stage gates. They’re validation rules that say you can’t move to Negotiation until five fields are filled in. Reps learn within a week that “TBD” satisfies all five.

The trouble is what a validation rule can see. Its formula looks at the record being saved and the records above it. It can’t count what hangs underneath. So it can demand that a text field isn’t blank, but it can’t ask whether a decision-maker is actually attached as a contact role, whether a quote exists, or whether a discovery call was ever logged.

Those are the gates worth having, and they need either a roll-up or a small piece of code that looks at related records before letting the stage change through. If the roll-up you want isn’t one Salesforce offers, there are ways to get it anyway. The principle: gate on evidence that exists in the org, not on fields a rep can type around. For where the line between clicks and code falls on something like this, the Flow vs. Apex breakdown covers it.

6. Late-stage deals with placeholder numbers

A deal in an early stage with no amount is normal. A deal in a late stage with an amount of zero, or one dollar, or a suspiciously round number that hasn’t changed since creation, is a forecast error waiting to be counted.

The check combines stage and amount: past a stage you choose, the amount must be present and non-trivial, and it should have changed at least once since the deal was created. Add the opposite case while you’re there, which is open deals with a close date more than a year out. Those are usually parking spots, not opportunities.

None of this blocks anyone. It labels. A manager who can filter out placeholder deals sees a smaller, truer pipeline, which is the entire point.

7. Deals owned by people who left

Every org has them. A rep leaves, their user is deactivated, and forty open opportunities stay under their name, quietly aging in a pipeline nobody is working.

The check is one line: open opportunities where the owner is inactive. The build is the reassignment rule. Hand them to the manager, or back to a queue, or to whoever now holds the territory, and write down which so it happens the same way every time. Ideally this runs as part of offboarding a user, not as a cleanup someone discovers in a board-prep panic.

Put all seven in one place

Seven flags on seven reports is its own mess. The piece that makes this stick is a single digest: each rep gets their own list before the pipeline review, grouped by check, with links straight to the records. Managers get the roll-up.

Then the review changes shape. Nobody spends it asking for updates, because the updates were requested by a machine two days earlier. If your team has already hit the ceiling of standard reporting on questions like this, the list of Salesforce reports you can’t build with the report builder alone will look familiar.

Why these stay unbuilt, and what changes that

Read the list again. A date comparison. A counter. A check for a related record. An owner lookup. It’s all small, and small is exactly the problem: too technical for a spare admin hour, too minor for a developer’s backlog. So the work gets done by a manager’s voice, weekly, forever.

That’s the gap Sentinel is aimed at. It makes your AI the developer of your CRM, so “flag every open opportunity that’s been in its stage longer than the limit for that stage, and send each owner a digest on Friday” is something you describe and watch get built. Salesforce changes go to a sandbox with tests first, every change is logged, and a snapshot is taken before each deploy. That doesn’t stop a bad rule from being written. It means you can see it and undo it the same day, which is how the safety layer is meant to work. Pricing is flat per Sentinel and is covered on a short demo call.

Start with number one. It’s the smallest, and it’s the one your forecast feels this week. Book a Demo Call and bring your last pipeline review’s list of “please update this” requests. That list is the spec.