It’s 9 a.m. on a Tuesday, and the client’s VP of Sales has just told the architect, “We want everything automated.” Across the call, a developer mutes himself, but you can almost hear the eye roll. “Everything” would take six months and a budget nobody approved.
This is where the job actually lives. Not in the diagrams or the certifications, but in the room where business hopes meet technical reality, and someone has to make the two agree. At senior levels, a Salesforce Solution Architect spends far less time clicking and coding than people expect, and far more time translating, deciding, and keeping people calm.
To show you what that looks like, let’s spend a single day on a live project. The client is fictional, but the situations aren’t. Picture Northwind Retail, a mid-market retailer midway through a move to Sales Cloud and Service Cloud, with some AI ambition down the line. Here’s how the day unfolds.
Table of Contents
What Is a Salesforce Solution Architect?
Before we dive into the day, a quick grounding for anyone earlier in their career.
A Solution Architect owns the solution. Their job is to take messy business requirements and turn them into a design that works, scales, and won’t fall apart the moment data volumes grow or the next phase kicks off. If developers are the construction crew, the architect is the lead designer, making sure the building won’t collapse.
The unofficial motto of the role is “it depends,” because almost every good answer starts there. Build custom or buy an AppExchange package? It depends on budget, timeline, and how unique the requirement really is. A big part of the work is validating designs against Salesforce’s Well-Architected framework, which defines what trusted, easy, and adaptable solutions look like.
Solution Architect vs. Technical, Application, System, and CTA
A Solution Architect focuses on everything within Salesforce and serves as the bridge between the functional and technical. A Technical Architect goes deeper into integrations, security standards, and code. Application Architect and System Architect are the two credential pillars that stack toward the top of the ladder. And the Certified Technical Architect (CTA) sits at the summit.
According to Salesforce’s own Trailhead credential page, qualifying for the CTA exam requires first earning the System Architect and Application Architect credentials, each of which is earned by completing four designer-level certs. In practice, plenty of architects do all of this work regardless of which exact badge they hold.
8:30 a.m. — Standups and the Quiet Art of Listening
The day rarely starts with one project. A consulting-partner architect is often spread across three or four engagements at once, so the morning is a run of standups, plus catching up on Slack threads and emails that piled up overnight.
The skill that matters here isn’t reciting status. It’s listening for what nobody is saying. A business analyst reads out a user story about “letting reps log a quick note,” and your brain immediately flags the hidden questions. Where does that note live? Does it sync to a marketing system? Will it break the reporting model someone else is building?
Most project risks don’t announce themselves. They hide inside assumptions that everyone in the room thinks are obvious and nobody has written down. Catching them early on a Tuesday morning is cheaper than catching them in user acceptance testing.
9:30 a.m. — Facilitating Discovery (Where Projects Are Won or Lost)
Next comes the discovery workshop with Northwind’s sales operations team. This is the part of the job that people underestimate the most.
The client says they want a button that emails a quote. Fine. But a good architect keeps asking “why” until the real process shows up. Who sends quotes today? What do they do when a customer asks for a discount? What happens when the deal involves three product lines and two approvers?
There’s an old reframing trick worth keeping in your back pocket. A client asks for a yellow apple. You could spend a week sourcing yellow apples, or you could ask why, learn they actually want something sweet and portable, and hand them a banana. The request and the need are not the same thing, and the architect’s job is to find the gap.
The Questions a Good Architect Asks
The best discovery sessions feel like a conversation that slowly gets to the truth, not an interrogation. A few questions that earn their keep:
- Who follows this process today, and what do they do when it breaks?
- Where does the data come from, and where does it need to go afterward?
- What does “done” look like for this team?
- What happens to this design when you have ten times the records?
The biggest mistake I see is solving only for today’s problem. If you know a loyalty program is coming next quarter, you design the data model with that in mind now, rather than ripping it apart later.
11:00 a.m. — Design Decisions and Documenting the “Why”
Late morning is the closest thing to quiet focus the day offers. Time to whiteboard the data model and make some real calls.
Northwind needs document generation for quotes. There’s a well-reviewed AppExchange tool that does it out of the box, and there’s a custom build the dev team is itching to try. Custom is more flexible. Packaged is faster and cheaper to maintain. The timeline just got tighter because of a delayed integration. So which wins?
That’s the decision. And here’s the part beginners skip: you write down why.
Architecture Decision Records and Design Authority
An Architecture Decision Record, or ADR, is a short note that captures three things. The business requirement, the technical reasoning behind your choice, and the trade-offs you accepted around cost, complexity, maintainability, and risk. It’s a lightweight log, not a novel.
Six months from now, when a new team member asks, “Why didn’t we just build this custom?”, the answer will be in the record, not in someone’s memory. On larger programs, a Design Authority or review board governs the decisions that really matter, so no single person quietly makes a choice that affects the whole architecture.
One practical habit: explore freely at the whiteboard, but only record a decision once it’s actually made. Logging every half-formed idea turns your ADRs into noise.
1:00 p.m. — Guiding Developers Without Doing Their Job
After lunch, a developer sends you a proposed data model for the new case routing logic. You jump into a sandbox, test the feasibility, and notice it’ll hit governor limits the moment Northwind loads their full customer history.
This is a teaching moment, not a takeover. The instinct, especially for architects who came up through development, is to grab the keyboard and fix it yourself. Resist that. Your job is to ask the question that makes the developer see the problem: “What happens when this query runs against 2 million records?”
Good architects design for scale, not just for the demo. That means staying alert to governor limits, large data volumes, and the right integration patterns. It also means being comfortable with the modern toolchain, including Salesforce DX, CI/CD, and source-driven development, because that’s how serious teams ship now.
2:30 p.m. — Managing Stakeholders and Navigating Scope Creep
The afternoon swings back to people. There is a design review with the Northwind leadership team, and two departments want different things from the same project. Someone has to be told ‘no’ today, and that task falls to you.
How to Say “No” (and Still Keep the Client’s Trust)
Saying no badly damages relationships. Saying no well builds them.
The right approach is to never simply say ‘no.’ Bring the reasoning, and frame it in terms the stakeholder cares about. “We can’t do that this sprint” lands very differently from “If we add this now, the go-live slips two weeks, and the regional launch you promised the board is at risk. Here’s what I’d recommend instead.” Same answer, completely different reaction.
Clients trust architects who tell them the truth early, even when it’s inconvenient. The ones who say yes to everything are the ones who blow up the project in month four.
When Scope Creeps — A Real Scenario
Back to Northwind. Halfway through the review, someone asks for “just one small Flow” to auto-assign leads by territory.
It is never just one small Flow. That request hides a territory data source, validation rules, an assignment fallback when no rep matches, and a dependency on a field that doesn’t exist yet. Scope creep usually arrives disguised as something tiny.
It shows up in a few flavors: business creep, where goals shift; feature creep, where the wishlist grows; effort creep, where the work turns out bigger than scoped; and hope creep, where someone reports progress that isn’t real.
The playbook is the same regardless. Name it early, route every new request through change control, and weigh it against the agreed MVP. Then pick one of three honest outcomes: approve it with a clear trade-off, defer it to Phase 2, or decline it. What you don’t do is quietly absorb it and hope nobody notices the timeline.
4:30 p.m. — Writing It Down and Closing the Loop
The last hour is unglamorous and important. You write up the day’s architecture decisions, update the backlog with the items from the review, and prep for tomorrow’s integration session.
This is the connecting element of the role. An architect manages various threads of conversation and ensures that, by the end of the week, they come together to form a coherent solution. If documentation is neglected, those threads gradually begin to unravel.
The Soft Skills That Matter More Than the Tech
Here’s the thing nobody tells you when you’re chasing the title. Technical depth gets you in the room. Communication keeps you there.
You can know every governor limit by heart and still fail as an architect if you can’t run a workshop, calm a frustrated executive, or explain a data model to someone who’s never seen Salesforce. The senior part of the job is mostly people.
The skills that separate good architects from great ones:
- Explaining complex ideas simply to a developer and a CFO on the same afternoon.
- Facilitating a room so that people who disagree leave aligned.
- Managing expectations before they become disappointments.
- Saying no with enough grace that it strengthens the relationship.
This is the hardest part to fake, and the part no certification can fully teach. It’s also why the role pays what it does.
How Do You Actually Become One?
There’s no single straight line, but the shape is fairly consistent.
The Typical Path
Most Solution Architects come up through the platform. Admin or developer, then senior consultant, then architect, usually after somewhere between five and eight years of hands-on Salesforce work. The timeline flexes with the complexity of the projects you’ve touched. Two years in enterprise integrations can teach you more than five years in simple orgs.
Certifications That Help
No cert is strictly required to call yourself a Solution Architect, but a few carry real weight. The B2B and B2C Solution Architect credentials are designed for exactly this role. The Application Architect and System Architect pillars are the next rung. And the CTA sits at the top.
CTAs are truly a rare sight. The entire review board process costs around $6,000, and there are fewer than 500 CTAs worldwide. It is not merely a formality to be ticked off, but a long-term commitment spanning several years.
What It Pays
The money is good. In the US, Glassdoor puts the range at roughly $152,000 at the 25th percentile to $240,000 at the 75th, with an average near $190,000. Numbers vary by source, region, and seniority, so treat them as a guide rather than a guarantee.
The Role in 2026: Agentforce, Data 360, and the AI Shift
The job is changing, and quickly.
At Dreamforce 2025, Salesforce rebranded Data Cloud to Data 360 and folded it under the Agentforce 360 umbrella, positioning it as the data layer that grounds AI agents in trusted information. For architects, that raises the bar. Understanding LLMs, retrieval-augmented generation, data unification, and the Einstein Trust Layer is moving from “nice to have” toward “expected.”
There’s a strategic point hiding in here. As AI takes over more routine building work, the reasoning and design part of the job becomes more valuable, not less. The people who can decide what to build are pulling ahead of the people who only know how.
Wrapping Up
Remember the VP who wanted everything automated? By the end of the day, that tension got resolved the way most do. You phased the roadmap, automated the high-value pieces now, parked the rest in Phase 2, and wrote the trade-off into an ADR so leadership and the dev team walked away pointing in the same direction.
That’s the job. Part technician, part translator, part diplomat. The technical knowledge gets you to the table, but the rarest skill in the room is the one that isn’t on any exam blueprint: helping a lot of people with competing goals agree on a single, sensible path forward.
If you’re weighing this path, take an honest look at where your strengths sit today. The platform skills you can study. The people skills are the long game, and they’re worth starting now.
Arun Kumar
Arun Kumar is a Salesforce 2x Certified professional with expertise in Marketing Cloud, Account Engagement (Pardot), Data 360, AI, and Agentforce. He focuses on designing and implementing scalable marketing automation solutions that improve customer engagement and drive performance. Passionate about innovation and continuous learning, Arun enjoys exploring the latest Salesforce technologies and sharing insights that help businesses build smarter, data-driven marketing strategies.
- Arun Kumar
- Arun Kumar
- Arun Kumar
- Arun Kumar
