Building for Today, Thinking About Tomorrow

Module 1 of 4 in the chapter Thinking Like a Security Architect, chapter 1 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: What does a security architect do that a good builder doesn’t?

When I teach this class, I tell the room up front that it has two goals. Some of you are here for the Platform Sharing and Visibility Architect certification. Others already have it, or just want to really understand how security works in Salesforce so you can do a better job. Both are fine, and this course is built for both. Everything that’s on the exam is here, and everything here would be worth knowing even if there were no exam.

But before we get into a single setting, I want to talk about the job itself.

What an architect is

I like to say that an architect is building for today and also thinking about tomorrow.

Building for today means meeting the business need in front of you. Someone needs to see the accounts in their region, so you make that work. That’s what a good builder does, and I’ll come back to builders in a minute, because you have to be one first.

Thinking about tomorrow means you’re also considering the things nobody wrote down. The different approaches you could take. The implied requirements. Reliability. Governance. You’re planning for growth: more users, more traffic, more business complexity, more systems connecting in. And you’re seeing problems ahead of time: where are the points of failure, how will errors be handled, how will we monitor this, how does it fail gracefully when something does go wrong, and how do we respond and recover.

Those are the elements of thinking like an architect. Now put the word security in front of each one, and you have this course.

Today and tomorrow in a security model

Here’s what that looks like when the subject is access.

Today is the request in front of you: the sales team needs to see their accounts, the service team needs to see cases, the managers need to see their people’s work. You can make every one of those work, and the users will be happy.

Tomorrow is everything that request didn’t mention. Who should not see these records? What happens when the company hires five hundred more people, opens a new region, or reorganizes the sales teams? What happens when partners or customers need to log in through a community? What happens when an integration user, or an agent, starts reading the same data? A model that only answers today’s question usually has to be rebuilt when one of those arrives.

And failure is the question most builders never ask: if this goes wrong, how would we know? If someone sees a record they shouldn’t, is there a log that shows it? Can we prove, to an auditor or to ourselves, that the model does what we say it does? This course answers both: proving the model is the chapter on testing the security model, and knowing who looked at what is the chapter on monitoring.

And here’s the hardest part. Suppose the model has failed, and some data is visible that shouldn’t be. Maybe it’s visible to internal users who shouldn’t have it. Or maybe you have a community, and the data is visible there. It might not be on any screen. Nobody might ever find it by clicking around. But we’re now in the days of adversarial AI. An attacker can use AI to try one URL after another, one port after another, one activity after another, until it discovers that something is visible. Data that no person would ever come across, a patient machine can find.

That’s the invisible bleed: data leaking where nobody is looking. It’s an unlocked door that nobody knew was there. Those doors used to stay hidden simply because no one had the time to try them all. They’re no longer invisible, because AI can find them.

Least privilege is a mindset

That’s why this chapter is called Thinking Like a Security Architect. It has to be a mindset, not a setting you turn on. Control access. Grant only the bare minimum, and grant it to the fewest people. That’s least privilege: each user gets only what they need, and everything else stays locked down. It’s how we handle the rise of AI and adversarial AI. If everything a user doesn’t need is locked, there’s nothing extra for anyone, or anything, to discover.

I know this can create a lot of friction in a team, especially with the business users. But you need to be thinking about the granularity of your users: not just the profile, but down to the permission set, and down to the individual. What is each person’s role? How will those roles change over time? And how do you both grant and revoke access? Most designs plan how access is given. Fewer plan how it’s taken away when someone changes teams or leaves. Module 3 of this chapter turns this mindset into four principles.

It’s also why my first rule for record access is one I’ll repeat later in the course: if there’s even a single user who shouldn’t see some of these records, start private. It’s easier to open up later than to lock it down later. Opening up is a setting. Locking down, after people have been seeing data for a year, is a project, and the data they already saw is already seen.

Here’s what that looks like in a real org. I worked with a customer that had designed its model wide open. Every employee could see every account and every record, and for years that was fine, because everyone who logged in worked for the company. Then the company started bringing on external sales teams and external contracting teams. To do their work in Salesforce, those contractors needed internal licenses. And the moment they had internal licenses, they were internal users, so the wide-open defaults applied to them too. The company didn’t want these new people seeing everything. So we had to lock it down: tighten the defaults, then build the sharing rules to give the employees back the access they’d always had, and grant the contractors only what their work needed.

The assumption was “internal users are our employees, and our employees can see everything.” It was true on day one. It stopped being true the day a different kind of user arrived, and nobody had planned for that day. That’s thinking about tomorrow: assume that at some point you’ll bring in additional users, and that you’ll need to restrict their access.

Become a great builder first

I tell everyone on the architect journey the same thing: a journey of a thousand miles begins with a single step. And my number one piece of advice for that journey is to become a great builder. Be really good at what you do. You can’t think about tomorrow’s security model if you don’t know exactly how today’s settings behave.

So get your hands on everything. Ask for more responsibility, join project reviews, look for chances to shadow people. And look around every org you work in. Whenever I’m in a Salesforce org or a sandbox, I look deep, and I learn from every org I touch. For security, I have a habit: in any org or sandbox, my first stop for record access is Setup, then Sharing Settings. In a few minutes you can see whether the org is mostly private or mostly public, which objects are controlled by their parent, and how much sharing has been built on top. That one page tells you a lot about the decisions somebody made, or didn’t make, before you arrived.

The other half of being a great builder is knowing the mechanisms. Salesforce gives you a lot of ways to control access out of the box: profiles, permission sets, roles, groups, sharing rules, teams, territories and more. You need to know them for two reasons: so you’re ready for the exam, and so you can architect a proper solution. There’s a lot you can do with what the platform already gives you, and there’s no reason to write code for it. Code should be saved for the use cases that go beyond the capabilities.

Getting in, and then what you can do

Everything in this course hangs on two words, and I want you to keep them apart from the very first page.

Authentication is getting in: someone, or some process, comes up to Salesforce and asks to be let in, and we verify who they are. Authorization is everything after that: now that we know who you are, what can you do?

The rest of the course follows the user through that door and on inside. I use a building to teach it. There’s the front door, where you prove who you are. There are the offices inside: you might be allowed into the accounting office and not into the HR office. And inside the HR office there are file cabinets, and even if you’re allowed in the room, the cabinets can be locked. Those are three different sets of controls in Salesforce, and module 2 walks through all three. The front door itself has its own chapter next, The Front Door: Logging In to Salesforce, because it’s shared with the Identity and Access course.

Click to enlarge

What the exam weighs

For those of you preparing for the certification, here’s how Salesforce’s exam guide divides the exam, as of when I last checked it (2026-10-28):

• Access to records: 39%
• Permissions to standard objects, custom objects and fields: 27%
• Implications of security model choice: 18%
• Access to other data (files, folders, reports and more): 16%

Notice what that tells you. Record access is the biggest single area, which is why the record-sharing chapters are the heart of this course. But almost a fifth of the exam is about implications: what your choice does to performance, to scale, to testing. That’s the “thinking about tomorrow” part, and it’s on the exam too.

One more thing the guide tells you: the exam’s questions align to the Winter ‘23 release. The platform has moved on since then, and module 4 of this chapter covers what changed. Learn both: what the exam expects, and how the platform works today.

The same guide lists what candidates often need help with, and security principles are on that list: least privilege, defense in depth, failing securely. That’s where module 3 of this chapter goes.

What an architect decides here

• Who the model is for today, and who it will have to hold tomorrow: more users, new regions, external users, integration users and agents.
• How little each user can be given (the bare minimum, to the fewest people, from the profile down to the permission set and the individual), and how that access is granted and revoked as roles change.
• Whether to start private and open up, knowing that locking down later is much harder.
• Which needs the platform’s built-in mechanisms meet, and which, if any, truly need code.
• How you would know if the model failed, and how you would prove it works.

Beyond the exam: what AI changes. Tomorrow’s users include agents. An agent comes through the same door and works under a user’s access, and it will read everything that access allows, quickly and across many records. I tell people to treat an agent like a curious human: give it only what it needs to do its job. Part 3 of this course has a chapter on what agents can see.

Explore

• Salesforce Certified Platform Sharing and Visibility Architect Exam Guide (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Platform Sharing and Visibility Architect credential (opens in a new tab), Trailhead (checked 2026-11-01)
• Salesforce Well-Architected: Trust (opens in a new tab), Salesforce Architects (checked 2026-11-01)