A stakeholder asks for one thing: a validation rule so reps can’t close a case without entering a resolution code. Half a day’s work, by the sound of it. Three weeks later you’re deep in a Flow that also updates a custom object, fires an email alert, and feeds a new field into a report someone in finance now quietly depends on. Nobody sat down and decided to build all that. It just accumulated, one reasonable-sounding addition at a time.
This is the most common way Salesforce enhancement work goes sideways. Not through bad estimates. Through scope that was never actually scoped in the first place.
Why this happens more on Salesforce than elsewhere
Declarative tools make it cheap to say yes to one more thing. There’s no build step, no deploy pipeline slowing anyone down mid-conversation. You can add a field, wire up a Flow branch, and show the stakeholder the result in the same meeting. That speed is the whole appeal of the platform, and it’s also exactly why scope drifts. When the cost of “just one more field” looks like zero, nobody treats it as a decision.
Stakeholders see this too, even if they can’t name it. They watch you build live, so every follow-up thought feels like it belongs in the same ticket. “While you’re in there, can it also notify the queue owner?” “Since we’re touching this object, can we clean up that other field too?” Each ask is small. The sum of them is a different project than the one you quoted.
Ask what breaks if the answer is no
Before you open Setup, ask the person requesting the change one question: what happens if we do exactly what you asked, and nothing else? If the honest answer is “that’s fine, it solves the problem,” you have a real scope. If the answer involves three other systems, a different team, or “well, we’d probably also need,” you’ve just found the second and third tickets hiding inside the first.
Most requesters haven’t separated the must-have from the nice-to-have in their own head yet. That’s not a failure on their part. It’s your job to pull that apart, not theirs to hand it to you pre-sorted. A five-minute conversation here saves a week of rework later.
Write the scope down before you touch anything
One sentence, before any configuration work starts: “This enhancement will do X for Y users, and nothing else.” Put it in the ticket. Get the requester to read it back and confirm. It feels bureaucratic for something that might take an afternoon, and that’s exactly why people skip it, and exactly why skipping it is how afternoons turn into weeks.
This isn’t about process for its own sake. A written scope is the thing you point back to when someone asks, two weeks in, why the notification piece isn’t in yet. Without it, every later addition feels retroactively like it was always part of the plan. With it, you have a clean line: that’s a new request, let’s size it separately.
Where the quiet third ticket usually hides
A few patterns show up again and again in Salesforce work specifically:
- Related automation. You add a field, and someone asks for a Flow to populate it automatically from somewhere else. That’s a second build, with its own edge cases and its own testing.
- Reporting asks. “Can we track how often this happens?” sounds like adding a report. It often means a new field, a new way of recording history, and a dashboard nobody scoped.
- Data cleanup. Half the time a new validation rule surfaces how messy the existing data is. Backfilling records so the new rule doesn’t lock users out of thousands of existing cases is its own project, and it’s rarely small.
- Permission changes. A new field or object usually needs field-level security and permission set updates across every profile that touches it. On an org that’s been customised for years, that step alone can take longer than the change that triggered it.
None of these are wrong to build. They’re just not the thing that was originally asked for, and they deserve their own estimate, their own priority, and their own sign-off.
A practical way to hold the line
When a new idea surfaces mid-build, and it will, don’t shut it down and don’t just absorb it either. Write it down as its own line item, note roughly how big it looks, and ask the requester to rank it against whatever else is in the queue. Most of the time this is enough to settle the person down: they weren’t attached to getting it this week, they just didn’t want the idea lost. Parking it properly protects both the current ticket and the idea itself.
Keep a running “related but separate” list on every enhancement of any real size. On a recent piece of platform support work, that list is what let a reporting change ship on time while three follow-on requests moved into the next sprint instead of silently inflating the first one. The original ticket closed in the time it was quoted for. The other three got proper attention later, with their own scope and their own testing, instead of being bolted onto something that was never designed to carry them.
What this actually protects
Scoping tightly isn’t about saying no to good ideas. It’s about making sure every piece of work gets built with the same care, instead of the first idea getting a proper design conversation and the fourth one getting squeezed in under time pressure with no testing to speak of. A Salesforce org that’s grown this way for a few years is usually easy to spot: automation that does three unrelated things because it was easier to extend the existing Flow than start a new one, fields nobody can explain the purpose of, permission sets that grew sideways instead of on purpose.
The fix costs almost nothing upfront. One sentence of written scope, one honest conversation about what breaks if you say no, and a parking list for everything else. Cheap insurance against the kind of technical debt that takes months to notice and years to unwind.