The Route Through This Course, and What Changed in 2025–2026

Module 4 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: How is this course laid out, and what has Salesforce changed in security recently that makes older advice out of date?

When I teach this class, I tell the room up front where we’re going. We control access into the org first, and that’s authentication. Then, once you’re inside, we look at what you can do. That’s authorization. Everything in this course hangs off that one path: the user logging in, walking through the building, and reaching a record.

So before we go room by room, here’s the whole route on one map. Then I’ll tell you what’s changed on the platform lately, because some of what you’ll read online, and some of what I said in my own earlier classes, isn’t true anymore.

The route, on the building

The course follows the same building from module 2: the front door, the offices and the file cabinets. It has three parts, and each one goes a level deeper. Part 1 helps you see the security model. Part 2 helps you design it. Part 3 helps you direct it across a whole company and beyond.

Click to enlarge

Part 1: The front door and the offices (see)

1. Thinking Like a Security Architect. This chapter: the building, the four principles, and this map.
2. The Front Door: Logging In to Salesforce. Authentication: passwords, MFA, IP ranges, login hours and sessions. It’s a chapter shared with other courses, because everyone comes through the same door.
3. Profiles, Permission Sets and Permission Set Groups. Who gets which offices, and how the assignment is managed.
4. Object and Field Security. What users can touch inside an office: the object and the field, and why hiding a field on a page isn’t securing it.
5. Steve’s 25 Ways to Share a Record: The Map. The pivot from the offices to the file cabinets. Every way a record can be opened to someone, on one page, before we go through them one at a time.

Part 2: The file cabinets (design)

6. Org-Wide Defaults, Ownership and the Role Hierarchy. How locked the cabinets start, who owns each file, and who sits above them.
7. Public Groups and Criteria-Based Sharing Rules.
8. Owner-Based Sharing Rules. These are very intricate, so they get a chapter of their own.
9. Config-Based Sharing: Manual Shares, Teams and Territories. Each has its own special uses.
10. Overrides and Implicit Sharing. View All and Modify All, and the access the platform gives you for free through parents and children.
11. Programmatic Sharing. Apex and Flow managed sharing, for when configuration runs out. Code should be saved for the use cases that go beyond what the platform can do on its own.
12. Files, Folders, Reports and Other Data. The things that aren’t records in an object but still need a lock.
13. Testing the Security Model. The three users from module 3, grown into a way to prove a whole model.

Part 3: Beyond the company and beyond the record (direct)

14. External Users: Sites, Communities, Licenses and Roles. A second door, for customers and partners.
15. Sharing Sets, Share Groups and Data Sharing for High-Volume Users.
16. Taking Access Away: Restriction and Scoping Rules. Most of this course is about granting. This is the one chapter about narrowing.
17. Sharing When Writing Apex: Secure Code. What your code can see when it runs, and whose rules it follows.
18. Encryption: Classic, Shield and Apex Crypto. Protecting the contents of the file, not only the cabinet.
19. Monitoring: Real-Time Events, Log Files and Transaction Security. The cameras in the building: who opened what, and when.
20. Beyond the Record: Agents. The newest people in the building aren’t people.
21. Data 360 Access: Data Spaces and Policies. Near core: data with an access model of its own, beside the share table.
22. Sharing at Scale. What happens to all of this with millions of records and thousands of users.
23. Reviewing a Security and Sharing Model. The capstone: you review a whole model, the way an architect is asked to on a real project.

Along the way, a delivery company called Steve Trucking gives you something real to design for, at checkpoints in Part 2 and in the capstone. You don’t need it to follow the rest.

Why this order

The order is the order I teach it, and it follows the user. You can’t reason about who sees a record until you know who got in and which offices they’re in. And you can’t design a sharing model one mechanism at a time without first seeing all the mechanisms together, which is why the map comes before the deep dives.

There’s another reason. You need to know these mechanisms for two things: to be ready for the exam, and to architect a proper solution. The exam rewards knowing what each mechanism does. A real org rewards knowing which one to reach for, and which ones to leave alone. Every chapter tries to give you both.

If you’re an admin or a developer, Part 1 stands on its own. You can take it, put it to work in your org or sandbox, and come back for Parts 2 and 3 when you’re ready.

What changed in 2025–2026

Now the part that dates this module. Salesforce has been tightening security across the platform, and Salesforce itself says why. Introducing the Summer ‘26 security changes, its Admins blog says the rise of AI has “completely shifted the cyber risk landscape” (Jen’s Top Summer ‘26 Release Features for Admins (opens in a new tab), checked 2026-11-01). That’s the same point from module 1: the doors that used to be invisible can now be found.

What I find interesting is the shape of the change. Salesforce’s access model is still grant-based, the same as module 3 described. What’s changing is the defaults. More and more, the platform starts closed and makes you open it on purpose. That’s least privilege, applied by Salesforce to its own settings. Here are the changes that matter most for this course, each with its date. Check the release notes for your own org, because dates move.

Profile names are on a need-to-know basis

The Enable Profile Filtering release update turns the Profile Filtering setting on by default. With it on, users can’t see profile names other than their own unless they have the View All Profiles permission. Salesforce: “This update was first available in Summer ‘26 and is enforced in Winter ‘27” (Enable Profile Filtering (Release Update) (opens in a new tab), Winter ‘27 release notes, checked 2026-11-01).

Why would a profile name matter? Because it tells someone how your org is built: who the administrators are, which users are integrations, where the powerful access lives. That’s need to know, from module 3, applied to the building plans and not only to the records. The architect’s job is to find the people who really do need to see every profile, such as delegated admins or the team that manages licenses, and give them View All Profiles before enforcement, rather than turning the setting back off for everyone. Include whoever builds login flows: with profile filtering on, “users can’t create or edit login flows” without View All Profiles (Limit Profile Details to Required Users (opens in a new tab), Salesforce Help, checked 2026-11-01). Chapter 3 covers it.

Code runs as the user, by default

For years, the first thing I’d check in someone’s Apex was whether it said with sharing, because if it didn’t say anything, it was easy to get wrong. That’s changed in two steps.

• Sharing. The current Apex Developer Guide says, “In Apex, sharing rules are always enforced by default,” and that with sharing is the default sharing mode. To skip sharing, a class must say without sharing (Enforce Sharing Rules (opens in a new tab), Apex Developer Guide, API version 68.0, checked 2026-11-01). Salesforce still recommends declaring a sharing keyword on every class.
• Object and field permissions. From Summer ‘26, Apex database operations, meaning queries, DML and Database methods, “now run in user mode by default,” enforcing the current user’s sharing rules, field-level security and object permissions. It’s a versioned change: it applies to code saved at API version 67.0 and later. The WITH SECURITY_ENFORCED clause is removed from that version, in favor of WITH USER_MODE. Salesforce calls it a “secure by default” paradigm, where code bypasses object and field security only if it’s explicitly set to system mode (Database Operations Run in User Mode by Default, Not System Mode (opens in a new tab), Summer ‘26 release notes, checked 2026-11-01).

That’s failing securely, from module 3, built into the language. Code that forgets to say what it should do now fails shut. Older code, saved at earlier API versions, still behaves the old way, so in a real org you’ll meet both. Chapters 11 and 17 work through what this means.

Profiles stay, but permission sets lead

In my 2023 class, I told the room that permissions on profiles were going away, and that Salesforce had announced a date. That plan has changed. Salesforce had announced the retirement of permissions in profiles starting in Spring ‘26, and then cancelled it “based on customer feedback and remaining feature gaps” (Permissions in Profiles Retirement Cancelled (opens in a new tab), Salesforce Help, published 2026-06-06, checked 2026-11-01).

The direction didn’t change, though. Salesforce still recommends a permission-set-led model: profiles for baseline settings such as default apps, login hours, login IP ranges, password policies and session settings, and permission sets and permission set groups for object permissions, field-level security and other access. It recommends starting users on the Minimum Access – Salesforce profile, or a clone. That’s what I recommend too, and chapter 3 shows how.

There’s a lesson in this one that goes beyond profiles. Treat a retirement date as a plan, not a promise. Design so you’re ready either way.

New tools for seeing and narrowing access (Summer ‘26)

A few smaller changes in Summer ‘26 make the principles easier to practice (Jen’s Top Summer ‘26 Release Features for Admins (opens in a new tab), checked 2026-11-01):

• A Field Access view in the Object Manager shows, for one field, the field-level security across profiles and permission sets in one place. Chapter 4.
• Grant Access Using Hierarchies on each queue. It stays on for existing queues so nothing changes, and it’s off for new ones. That’s the CEO question from module 3, now with a switch on the queue. Chapter 6.
• Faster recalculation of criteria-based sharing rules after you change an organization-wide default, run in parallel. Chapters 6 and 21.

At the front door, and beyond this course

Summer ‘26 also brings stronger login protections: expanded MFA requirements, phishing-resistant methods for privileged accounts, and step-up authentication when a user’s behavior looks unusual. Those belong at the front door, so they’re in chapter 2, The Front Door: Logging In to Salesforce.

The biggest set of 2025–2026 changes is in how integrations connect: connected apps giving way to External Client Apps, and older OAuth flows being retired. Those are covered in the Integration Architect course. In this course, they show up where an integration user is just another user in the building.

What this means for what you read

When you read a blog post, watch a video or study from an older course, including my own, check its date against these changes. “Remember to add with sharing” is still good advice, but it’s no longer the whole story. “Permissions on profiles are being retired” is no longer true. “Any user can see the list of profiles” isn’t true once profile filtering is enforced. Every number and date in this course is written with the date I checked it, so you can tell how fresh it is, and I’ll keep updating them.

What an architect decides here

• Which part of the course a problem belongs to: the front door, the offices, the file cabinets, or beyond.
• Which users truly need View All Profiles before profile filtering is enforced.
• For existing Apex, which classes are saved below API version 67.0, and whether each one should run in user mode or in system mode, decided on purpose.
• How far the org is toward a permission-set-led model, and what still lives on profiles that shouldn’t.
• How the team will notice the next release update that changes a security default, before it’s enforced.

Explore

• Enable Profile Filtering (Release Update) (opens in a new tab), Salesforce Winter ‘27 release notes (checked 2026-11-01)
• Database Operations Run in User Mode by Default, Not System Mode (opens in a new tab), Salesforce Summer ‘26 release notes (checked 2026-11-01)
• Limit Profile Details to Required Users (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Enforce Sharing Rules (opens in a new tab), Apex Developer Guide, API version 68.0 (checked 2026-11-01)
• Permissions in Profiles Retirement Cancelled (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Jen’s Top Summer ‘26 Release Features for Admins (opens in a new tab), Salesforce Admins blog (checked 2026-11-01)