To require a rejection reason on Salesforce leads, add a "Rejection Reason" picklist field to the Lead object, then enforce it with a validation rule that fires whenever the lead status moves to your rejected or unqualified value — the rep cannot save until a reason is chosen. Most teams pair this with a dedicated reject button or Path guidance so rejection is a deliberate, guided action instead of a casual status edit, and a report that groups rejections by reason so marketing and sales leaders can see patterns. The result: every rejected lead carries a reusable signal — wrong fit, wrong timing, bad data, lost to competitor — instead of vanishing into a status nobody trusts. This guide covers the design decisions, the build options, and the reporting loop that makes rejection data worth requiring.
Every rejected lead is a verdict on something — the lead source, the campaign, the timing, the data quality. When rejection is just a status picklist value, that verdict evaporates. Six months later, the questions start: Why did the webinar leads die? Is the purchased list any good? Did reps reject those leads because they were bad, or because following up was harder than closing the new inbound?
Without reasons, nobody can answer. Marketing keeps spending on sources that sales quietly distrusts. "Recycled" leads go back into nurture with no note about why they came out. And the rejection status itself rots — some reps use it, some delete leads, some leave them "working" forever, so the funnel report is fiction at every stage.
Requiring a reason at the moment of rejection is the cheapest fix in CRM: one field, one validation rule, one report. The discipline it creates pays out in every downstream decision.
Three design choices determine whether the system works or gets routed around:
The classic build is a single validation rule on the Lead object:
| Approach | Strengths | Watch out for |
|---|---|---|
| Validation rule | Simple, bulletproof, applies everywhere including imports and API | Applies everywhere — including automations you forgot about |
| Screen flow on a reject action | Guided experience, can ask follow-up questions per reason | Only governs reps who use the action; direct edits bypass it |
| Dynamic Forms visibility | Reason field appears only when status is rejected | Cosmetic, not enforcement — pair with a validation rule |
The pattern that holds up: validation rule as the enforcement floor, a reject quick action or flow as the guided front door, and dynamic form visibility as the polish. Any one of them alone leaves a hole.
Build one report — leads grouped by rejection reason, filterable by source, campaign, and date — and three conversations change immediately:
Put the report on the sales and marketing leadership dashboard. A reason field nobody reviews teaches reps that the reason does not matter, and compliance decays.
Vantage Point designs lead lifecycles as part of Salesforce implementation and advisory work — statuses, rejection and recycle paths, validation rules, and the reporting that keeps them honest. Where the leak is really process adoption rather than configuration, advisory and change management support gets the team actually using the design.
Vantage Point is a Salesforce and HubSpot Solutions Partner and is employee-owned. Senior consultants only — no junior handoffs; the experts you meet are the experts who deliver.
Yes — that is exactly what validation rules do. The rule checks whether the status is being set to your rejected value and the Rejection Reason field is blank, and blocks the save with an error message until the rep chooses a reason. The field stays optional in every other situation.
Five to eight options that separate fit problems from timing problems: common sets include No budget, Wrong fit, Bad data or unreachable, Chose a competitor, No response, and Timing—revisit later. The split matters because fit rejections inform targeting while timing rejections feed nurture and recycling.
It can, because validation rules fire on API and import writes too. Test every tool that touches lead status, and if needed scope the rule to exclude specific integration users — with the tradeoff documented so exceptions do not silently multiply.
A dedicated reject action is the better pattern: it sets the status, prompts for the reason, and can ask structured follow-ups. Some orgs also restrict direct status edits so the guided path is the only path, but at minimum make the button the obvious, easy choice.
Create a lead report grouped by Rejection Reason with columns for lead source, campaign, and owner, then add it to the sales and marketing dashboard reviewed weekly or monthly. Trends by source and over time are where the value lives — a single month's snapshot mostly confirms anecdotes.
The concept is identical — a required closed-lost or rejection reason enforced at the stage change — but the mechanics differ: HubSpot uses required properties on deal or lead status changes and pipeline settings rather than validation rules. The picklist design and reporting discipline carry over directly.