Thinking Like a Security Architect
This content is not available in your language yet.
Chapter 1 of Securing Salesforce: Sharing and Visibility, Part 1: The Front Door and the Offices. New here? This chapter is the start of the course.
An architect is building for today and also thinking about tomorrow.
Today is the request in front of you: the sales team needs to see their accounts. Tomorrow is everything that request didn’t mention. Who should not see these records? What happens when the company grows, when partners log in through a community, when an integration user or an agent starts reading the same data? And what happens when something fails, and data is visible that shouldn’t be?
That last question matters more every year. A door nobody knew was unlocked used to stay hidden, because no one had time to try them all. Those doors are no longer invisible, because AI can find them. So security can’t be a setting you turn on. It has to be a mindset: grant only the bare minimum, to the fewest people.
This chapter gives you that mindset and the picture the rest of the course is built on. It doesn’t teach a single Setup screen in depth. It teaches you how to think before you open one.
The ideas in this chapter
Section titled “The ideas in this chapter”- Building for today, thinking about tomorrow. Meet the need in front of you, and plan for growth, new kinds of users and failure.
- Least privilege is a mindset. Grant the bare minimum, to the fewest people, and plan how access is revoked as well as how it’s granted.
- It’s easier to open up later than to lock it down later. If even one user shouldn’t see some records, start private.
- Become a great builder first. Know the platform’s mechanisms well. Code should be saved for the use cases that go beyond the capabilities.
- Authentication, then authorization. Getting in is one question. What you can do once you’re in is another.
- The building. The front door (who are you?), the offices (can you see the object, the field?), and the file cabinets (which records?): three separate sets of controls.
- Most restrictive wins. Where the offices and the cabinets meet, Salesforce doesn’t add them together. View All and Modify All are the one exception.
- Four principles. Least privilege, need to know, defense in depth and failing securely, each shown in a real org.
- Hiding isn’t securing. A field kept off a page can still bleed through list views, reports and global search.
- Prove it with three users. The administrator, a user the record is shared with, and one it isn’t.
- The defaults are moving toward closed. Salesforce’s 2025–2026 changes start more things locked and make you open them on purpose.
The building
Section titled “The building”I teach the whole course on one picture. The user comes to the front door and proves who they are. Inside, they’re allowed into some offices and not others. And in the office, the file cabinets are locked, and each one opens only for a reason.
When someone can’t see a record, or sees one they shouldn’t, ask in that order. Did they get in, and how? Which office are they in? And how is this record’s cabinet opened to them, or why isn’t it? Most confusing access problems become simple once you know which layer you’re in.
The path through this chapter
Section titled “The path through this chapter”Four modules, each standing on its own.
- Building for Today, Thinking About Tomorrow. What a security architect does that a good builder doesn’t: today, tomorrow and failure; the invisible unlocked door that AI can now find; least privilege as a mindset; becoming a great builder first; authentication and authorization; and what the exam weighs.
- The Building, the Offices and the File Cabinets. The three sets of controls, each drawn close up; why Edit on a permission set and Read Only on a record gives Read; and View All and Modify All as the one time the office opens the cabinets.
- Four Principles, the Salesforce Way. Least privilege, starting from the Minimum Access – Salesforce profile; need to know, with the CEO and the complaint; defense in depth, where hiding isn’t securing; failing securely; and proving the model with three users.
- The Route Through This Course, and What Changed in 2025–2026. All 23 chapters on the building, and the recent security changes, each dated and cited: profile filtering, code that runs as the user by default, and permission sets leading while profiles stay.
Then check what stuck with the study guide.
What an architect decides here
Section titled “What an architect decides here”- Who the model must hold tomorrow, not only today: more users, new regions, external users, integration users and agents.
- How little each user can be given, and how that access is granted and revoked as roles change.
- Which layer a requirement belongs to: the front door, the object and field, or the record.
- Which organization-wide defaults start Private, and where each confidential record’s branch of the role hierarchy begins.
- Which sensitive fields must be secured, not only hidden on a page.
- Which additions could fail open (public defaults, View All, guest access, system-mode code), and who signs off on each.
- How the model will be proved, positive and negative, before anyone relies on it.
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. Treat an agent like a curious human: give it only what it needs to do its job. Part 3 has a chapter on agents, and one on Data 360.
Explore
Section titled “Explore”- Salesforce Well-Architected: Trust (opens in a new tab), Salesforce Architects (checked 2026-11-01)
- Platform Sharing Architecture (opens in a new tab), Salesforce Architects (checked 2026-11-01)
- Salesforce Certified Platform Sharing and Visibility Architect Exam Guide (opens in a new tab), Salesforce Help (checked 2026-11-01)
