Before You Build: Solution Design for Salesforce Projects
The most expensive Salesforce mistakes don't happen in code. They happen in conversations that never took place.
The Problem with Jumping Straight to Build
Someone gets approval for a Salesforce project. A sandbox gets spun up. Consultants are onboarded. And within weeks, there are flows being built, fields being created, and page layouts being configured — all before anyone has properly agreed on what the project is actually supposed to achieve.
But projects aren't the only place this happens. Most Salesforce orgs are shaped just as much — or more — by the steady drip of change requests that come through, each one treated as too small to warrant proper design thinking. Add this field. Make that field required. Can we just add a checkbox to track this? Each request seems small. Reasonable, even. And because Salesforce makes it fast to say yes, the answer usually is yes — often without anyone asking why.
The result is an org that accumulates changes the way a house accumulates furniture. Individually, each piece made sense. Together, they don't quite fit, and nobody's sure what to move.
This isn't laziness. It's momentum. There's pressure to show progress on projects, and pressure to be responsive on requests. Solution design gets treated as overhead — the thing you do when you have time, which is never. The cost shows up later: rework that could have been avoided with a single whiteboard session, an integration designed around the wrong data model, a process that mirrors how the business used to work rather than how it wants to work.
Solution design doesn't prevent all of this. But skipping it almost guarantees some version of it.
Start With the Outcome, Not the Feature
The single most important shift in Salesforce solution design is learning to hear what someone asks for and then asking why.
"We need a case management process" is a feature request. "Add this field" is a feature request. So is "make that field required." They arrive at different scales, but they share the same problem: they describe a solution before anyone has defined the need.
The better question is always: what are you trying to achieve? "We need to reduce customer resolution time and give our service team visibility across accounts" is a business outcome. So is "our ops team is tracking this in a spreadsheet and keeps getting it wrong." One leads to a project. The other might be a single field — or it might be a process change, a report, or data that already exists in the org. You don't know until you ask.
Outcomes matter because they give you a benchmark. When decisions come up — and they always do — you can test options against something real: does this get us closer to that outcome, or further away? Without them, decisions get made on preference, habit, or urgency.
The discipline is the same regardless of the size of the ask: resist the pull toward a solution until you understand what success looks like. Write it down. Get agreement on it. It becomes the foundation for everything that follows.
Understanding the Need: The Questions That Matter
Good solution design is mostly good questioning. Before you open a whiteboard or think about data models, you need to understand the current state, the desired state, and the gap between them.
Some of the most useful questions:
What does the current process look like, and where does it break? Don't assume the pain is where the stakeholder says it is. Ask them to walk you through it step by step. The real friction often surfaces in the details.
Who owns this process, and who's affected by it? Salesforce solutions cross team boundaries constantly. A Sales Cloud implementation touches sales, sales ops, finance, and sometimes marketing. Understanding ownership early prevents turf wars later.
What does good look like in twelve months? This forces concrete thinking. "Better reporting" isn't an answer. "My VP can see pipeline by region without asking three people for spreadsheets" is.
What has been tried before? Failed previous attempts are gold. They tell you where the complexity really lives, what organizational constraints exist, and what not to repeat.
Where does Salesforce fit — and where doesn't it? Not every problem belongs in Salesforce. Part of the architect's job is being honest about where the platform is the right tool and where it's being asked to do something it shouldn't.
The output of this phase isn't a document. It's a shared understanding — between you, the stakeholders, and the delivery team — of what you're actually solving.
Designing the Solution
With outcomes defined and the need understood, you can start shaping the solution. This is where architecture decisions get made — and where experience matters most.
In Salesforce terms, the key decisions typically cluster around a few areas. Data model is foundational — get it wrong and everything built on top of it becomes fragile. Process design determines whether you're using flows, approval processes, or custom Apex — and the answer should come from the complexity of the requirement, not from what the developer is most comfortable with. Integration points need to be identified early, because they have a way of surfacing constraints that reshape everything else.
The governing principle here is: design to the outcome, not to the feature list. A stakeholder asking for a custom object to track something might actually need a junction object, a process change, or a report. The feature request is a starting point for a conversation, not a specification.
Declarative-first is generally the right instinct on Salesforce — configuration over code, where the requirement genuinely supports it. But declarative-first doesn't mean declarative-always. The honest answer sometimes is that a requirement needs custom development, and pretending otherwise creates technical debt with extra steps.
Not Every Request Needs a Workshop
Full solution design has a cost — time, focus, stakeholder availability. Applying it uniformly to every change request is impractical, and treating a minor tweak the same as a platform initiative will erode trust with the business fast.
The real skill is calibration: knowing when a request warrants proper design work and when a lightweight assessment is enough.
A few signals that a request needs full solution design treatment: it touches the core data model; it affects multiple teams or system integrations; it changes a process that other automations depend on; or it's been described as "simple" by someone who hasn't looked closely yet. That last one, in particular, should always prompt a second look.
A request is probably a safe tweak if it's genuinely isolated — a new field on an object with no downstream dependencies, a report for a single user, a picklist value addition. Even then, the right question is: does this fit the existing design, or does it pull against it? A change that seems small but contradicts an architectural decision already made isn't a tweak. It's a design conversation waiting to happen.
A useful middle ground is a lightweight design check — not a full workshop, but fifteen minutes with the right people to ask: what's the outcome, what's the impact, and does this fit what we've already built? Most requests can be assessed and progressed in that time. The ones that can't are telling you something.
The Artifacts That Keep Everyone Honest
Solution design doesn't need to produce a 60-page specification document that nobody reads. It needs to produce a small set of artifacts that keep the team aligned as the project moves forward.
A solution overview — one to two pages — that captures the business context, the agreed outcomes, and the high-level approach. This is the document you hand to someone joining the project mid-stream.
A key decisions log that records the significant choices made during design, and crucially, why they were made. Decisions that look strange six months later usually have a good reason behind them. Write it down before you forget.
An open questions list that tracks anything unresolved. The instinct is to close questions before moving forward. The smarter move is to be explicit about what's still open, who owns the answer, and what's blocked until it's resolved.
These aren't bureaucracy. They're the difference between a project with shared context and one where the same conversation gets had three times. And for smaller requests, even a single line in a decisions log — "added X field to support Y outcome, approved by Z" — is enough to make the change traceable.
The Bottom Line
Solution design is not a phase you complete before the real work starts. It's a discipline that runs through the entire project — and through every request that lands in between.
The teams that do this well don't spend more time designing. They spend less time rebuilding. They arrive at go-live with a solution that the business recognizes as solving the problem they actually had — and they maintain an org that they can still reason about two years later.
That starts with the right conversations, asked in the right order, before anyone opens a sandbox.