Every Salesforce implementation starts with a business need. It could be improving customer onboarding, simplifying processes, or giving teams better visibility into their operations. But before jumping into a solution, architects need to understand what the business is actually trying to achieve.
This is where business analysis becomes essential. Understanding stakeholder expectations, existing workflows, and business challenges helps architects make better decisions from the beginning. Without that clarity, even a technically sound Salesforce solution can end up solving the wrong problem.
An excellent Salesforce architecture is not just about knowing what the platform can do. It’s about understanding the business well enough to decide what to build, why it matters, and how the solution can support future growth.
Table of Contents
The Data Model Is the Output, Not the Starting Point
A distinction that changes everything: a data model built to fulfill a specific request is fundamentally different from one designed to meet a business’s needs. The first does exactly what the ticket says and nothing more. The second holds up when the ticket turns out to be wrong, which it often is.
Salesforce’s own architects make this point better than I can. In an August 2026 post on the Salesforce Architecture blog, CTA Miriam McCabe argues that requirements rarely arrive clean. They show up as a jumble of why (the actual business need), what (the high-level ask), and how (someone’s pre-baked solution). The architect’s job is to pull those apart.
Her example should make every admin pause. A requirement reads “the solution shall include a new custom data object.” That sounds like a what. It’s really a how — a solution someone settled on before confirming the requirement even calls for a new object. Whether the data belongs on a custom object, a standard object, or a related list of files is your decision to make once you understand the shape of the data.
Flip that order, and the trouble starts. Build the object first, and every later decision has to bend around a choice nobody validated.
What Business Analysis actually means here
I’m not talking about a job title. Business analysis is a discipline, and every architect has to own it whether or not a dedicated BA sits on the project.
It means interrogating requirements instead of accepting them. Mapping the process the way it actually runs, not the tidy version in the kickoff deck. Knowing who touches each record and when. Asking what the reporting has to show a year from now. Pressure-testing the edge cases until the real need is unambiguous.
Do that work, and the data model stops being a creative act. It becomes almost obvious, because the shape of the business has already told you what the objects need to be.
How Skipping Analysis Quietly Rots an Org
Salesforce technical debt rarely arrives as a dramatic failure. It accumulates quietly, one reasonable-sounding decision at a time, until the org is expensive to change and nobody can quite say why.
The consequences of this can prove dangerous down the line. In a May 2026 architecture blog post, Salesforce architect Neha Nagori explains that she agreed to handle tax calculations directly within Salesforce for a real estate client. At the time, it seemed like a sound approach. However, once this path was chosen, all subsequent decisions depended on it. Consequently, reversing those decisions would have meant untangling a complex web of dependencies that had built up over the years.
That’s the part junior admins don’t feel yet, and architects can’t afford to ignore. An admin reacting to tickets can make a shaky call and fix it next sprint. An architect’s single design decision propagates — into the sharing model, the reporting, the integrations, and every enhancement that follows. One object choice, made before anyone understood the process, doesn’t stay one problem.
Here’s how a single premature object decision tends to spread:
None of these announce themselves on day one. They surface months later — a report that won’t group correctly, a sharing rule that can’t express what security actually needs — by which point the structure is load-bearing, and the fix is expensive.
The Analysis That Produces a Good Schema
So what does the work actually look like? The cleanest way I’ve found to think about it borrows a progression older than Salesforce itself: conceptual, then logical, then physical. The trick is realizing that the first two belong to business analysis. Only the physical model is the schema you build.
Start conceptual — in the business’s language.
A conceptual model names the things the business cares about, in the words the business uses. Not “Account,” “Organization,” or “Clinic,” or “Dealership,” whatever they actually say.
This sounds pedantic. It isn’t. The moment you write “Account,” you’ve quietly assumed a Salesforce solution before confirming what the business even means. Keep the names in plain business language, and you give yourself room to validate the relationships — this belongs to that; one of these can have many of those — with stakeholders, before any of it maps to objects.
Map the real process before you build
Before you model anything, draw the process. I mean literally draw it. UPN, or Universal Process Notation, is a lightweight, vendor-neutral way to do this, and Salesforce teaches it on Trailhead. It needs no special software and reads plainly enough that a stakeholder can correct you on the spot.
McCabe makes a claim about this I’ve found true over and over: ten minutes spent sketching the process pays for itself every time. Sometimes the sketch reveals the cleanest answer is no new system at all. You can’t see that from inside Schema Builder.
Write requirements as outcomes, not instructions.
Finally, capture requirements as outcomes — what the user needs to accomplish and why — rather than a list of fields to build. User stories with clear acceptance criteria do this well. They pin down what “done” means without prescribing the how, which keeps the design decision where it belongs. Vague requirements are a direct source of rework, and this is where you stop them.
What Salesforce Itself Is Telling You
If this all sounds like one blogger’s opinion, it isn’t. The pattern is baked into Salesforce’s own frameworks and certifications.
Well-Architected: Old pillars and New
When Salesforce launched its Well-Architected framework at Dreamforce ’22, the original structure rested on three pillars: Trusted, Easy, and Adaptable. The Easy guidance is clear about where design comes from. To reach an easy solution, it says you must understand business priorities, including your users’ needs and the day-to-day realities of their work.
In September 2026, Salesforce reorganized and reworked the framework into five pillars: Trust, Reliability, Operational Excellence, Resource and Cost Optimization, and Fairness. It is designed to help architects balance business requirements and long-term technical quality. The most significant aspect of this release is that architects must understand not only what *can* be built, but also what *should* be built—and why. While the phrasing differs, the core message remains the same: it is essential to fully understand something before building it.
The Certifications reward requirements-driven design
Look at what the exams actually test. The Salesforce Certified Business Analyst credential leads with Customer Discovery and stakeholder collaboration, not schema. The Platform Data Architect exam is scenario-based: it asks you to design a data model that scales given a customer scenario, not to recite relationship types in a vacuum. And at the top, the CTA Review Board expects you to defend your design trade-offs to stakeholders out loud. Schema knowledge is assumed. Judgment is what gets graded.
The Reframe for Senior Admins and Aspiring Architects
I want you to take a new perspective from here: “Becoming better at architecture” does not mean memorizing more design patterns or learning some clever new way to model junction objects. It means pausing at the beginning, fully understanding the problem, and then crafting a design based on that understanding.
It’s the same analysis-before-architecture principle every beginner is taught, applied where the stakes are highest, and the cost of skipping it is steepest. The market has noticed, too. Demand for Technical Architects jumped 27% year over year in the 2025 Salesforce Talent Ecosystem Report, and the orgs driving that demand are usually the ones that grew through years of piecemeal building without architectural oversight.
So here’s the next step, and it’s small. On your next request, before anything, ask one question: what is the business actually trying to do here? Then don’t move until you can answer it without guessing. That one habit, repeated, is most of what separates an org that scales from one that needs a rebuild in eighteen months.
Frequently Asked Questions
No. Start with business analysis — the process, the people, the reporting needs, and the edge cases. The data model is the output of that understanding. Designing objects first bakes unvalidated assumptions into a structure that’s expensive to change later.
Discovery and process mapping. Interview stakeholders, map how the process actually runs, separate the real business need from someone’s pre-chosen solution, and write requirements as outcomes. A conceptual model in plain business language comes before any object design.
No. The Salesforce Certified Business Analyst credential is not a prerequisite for any architect certification. It’s genuinely useful for building discovery and requirements skills, but the architect path runs through the App Builder, Developer, and architect-specialist exams instead.
As of September 2026, Well-Architected has five pillars: Trust, Reliability, Operational Excellence, Resource and Cost Optimization, and Fairness. These replaced the original three — Trusted, Easy, and Adaptable — from the framework’s 2022 launch.
Only after you can explain in two sentences why a standard object won’t work, and you know what standard object the custom one would replace. If the data could live on an existing object or a related list, it usually should. Confirm the need before building.
Most debt traces back to building before understanding — automations stacked on unvalidated assumptions, objects designed to satisfy a ticket instead of a process. One early design choice ripples into sharing, reporting, and integrations, and by the time the gaps show, the structure is load-bearing.
Priya Rastogi
Priya is a 3x Salesforce Certified who believes in the power of continuous learning and collaboration. She’s passionate about exploring how Salesforce can simplify work, boost productivity, and create better user experiences. When she’s not experimenting with new features or automating processes, Priya enjoys connecting with fellow Trailblazers and sharing insights to help others grow in their Salesforce journey.
- Priya Rastogi
- Priya Rastogi
- Priya Rastogi
- Priya Rastogi
