콘텐츠로 이동
SteveTechArcSteveTechArc Courses

Study guide

이 콘텐츠는 아직 번역되지 않았습니다.

Study guide for chapter 3 of the Securing Salesforce: Sharing and Visibility course. Read the seven modules first; this page helps you check what stuck.

About this study guide. It’s built only from this course’s own content and the published Salesforce exam guide’s list of objectives. It is never based on real exam questions, and it doesn’t claim to know what’s on the exam. If you’ve taken the exam, please don’t send me questions from it: the certification agreement forbids sharing them, and memorizing answers is the wrong way to become an architect anyway.

This chapter carries two of the Sharing and Visibility exam’s objectives: recommending object permissions for a set of users, and the license limitations that affect what you can give them. Its section, Permissions to Standard Objects, Custom Objects, and Fields, is 27% of the exam. The exam guide aligns to Winter ‘23, so the changes since then are in their own list at the end.

For the Exam

Section titled “For the Exam”

Tick them off as you go. Each one links to where it’s taught.

Profiles (supports OBJ-1)

Permission sets (supports OBJ-1)

  • I know permission sets only add access, and that a user has the permission if any of them grants it. (Many of something)
  • I size permission sets by task, not by job title, and split permissions only where they’re ever given apart. (Small, but not too small)
  • I know the kinds: custom, standard (they don’t count toward the limit, but their clones do), from managed packages, and the one inside every profile. (The kinds of permission sets)

Permission set groups and muting (supports OBJ-1)

  • I bundle permission sets into a permission set group for each persona, and know a user gets the combined permissions of the group. (A group is the job)
  • I expect every team that builds a subsystem to ship at least three permission sets for it (read-only, user and admin), and build each persona’s group as an assembly across subsystems. (Each team ships its permission sets)
  • I can see what a group gives on one page: the Combined permissions view and View Summary. (One page for one person)
  • I know a group can have one muting permission set, that muting works only for the group’s members, and that a user who gets the same permission another way keeps it. (The mute button)
  • I know a group holds permission sets and one muting permission set, but no other group. (No groups inside groups)
  • I know groups are calculated, what Updated, Outdated, Updating and Failed mean, and that Apex tests should assign permission sets, not groups. (Groups are calculated)

Access that ends (supports OBJ-1)

  • I know an assignment can expire at 11:59 PM on a date, in a time zone I choose, once the setting is turned on. (Access with an end date)
  • I know an expired user stays assigned but can’t use those permissions, and keeps access granted elsewhere. (What happens on the date)
  • I know a permission set or group with Assign Permission Set, Manage Profiles, Manage Users or Permission Sets can’t have an expiration date. (The most powerful access can’t expire)
  • I know a session-based permission set is assigned but inactive until activated, by a flow or the SessionPermSetActivation object, and lasts only for that session. (Access that sleeps)
  • I know a session-based permission set inside an ordinary group needs no activation, and that a session-based group makes everything in it session-based. (The trap)

Assigning at scale (supports OBJ-1)

  • I know a user access policy grants or revokes permission sets, groups, licenses, public groups and queues for users who match its criteria. (A rule instead of a checklist)
  • I know the difference between manual and active policies, and that only one active policy applies when several match: the lowest Order. (Two kinds)
  • I know an active policy applies to existing users only when their record changes to match. (The catch)

Licenses (supports IMP-2)

  • I know every user has exactly one user license and any number of permission set licenses and feature licenses, and that a permission can only be given if a license includes it. (Locks and rings of keys)
  • I can tell the standard internal licenses apart: Salesforce, Salesforce Platform, Salesforce Integration, Identity Only. (The user licenses you’ll meet)
  • I know a permission set tied to a license can only include what that license allows, and that a clone keeps its license. (Should a permission set carry a license?)

Delegation and seeing access (supports OBJ-1)

  • I know what a delegated admin can do for users in their groups, and that they can’t assign anything with Modify All Data or modify permission sets. (Sharing the work)
  • I know where to look to see a user’s access: the user’s View Summary, a permission set’s or group’s summary, and Object Access in Object Manager. (Seeing a user’s access)

One grant, three ways in (supports OBJ-1 and IMP-2)

  • I know a person, an integration and an agent all come in as a user, with a user license, a profile and permission sets. (Every way in is a user)
  • I know the integration user: one per integration, the Salesforce Integration license, the Minimum Access - API Only Integrations profile, and permission sets for the job. (An integration)
  • I know an app set to Admin approved users are pre-authorized is opened by profile or permission set, and that Use Any API Client bypasses it. (An integration)
  • I know a service agent’s agent user is an integration user with minimal access by default, and an employee agent is opened by Enabled Agent Access on a permission set or profile. (An agent)

What changed since the exam’s Winter ‘23 alignment (dated, beyond the exam today)

  • I know Salesforce cancelled the retirement of permissions on profiles (published 2026-06-06), and still recommends profiles for baseline settings and permission sets for access. (What still lives on the profile)
  • I know the Salesforce Platform Login license, available from October 15, 2024, and the Unified Employee license. (The user licenses you’ll meet)
  • I know that since Winter ‘26, permission set licenses are removed automatically when you unassign a permission set or group, except through user access policies and a few other cases. (Licenses and permission sets together)
  • I know the Field Access Summary (Summer ‘26) shows one field’s access across all profiles, permission sets and groups. (Seeing a user’s access)
  • I know that since Summer ‘26, transaction security policies can monitor, alert on and block changes to critical permissions on profiles, and that profile filtering is enforced in Winter ‘27. (Watching the profiles you keep)

Beyond the Exam

Section titled “Beyond the Exam”

The exam is the floor, not the ceiling. These are the habits from this chapter that an architect needs, whether or not a question ever asks about them.

  • Keep the profile light: the door and the defaults, nothing else.
  • Count the doors, not the job titles, when you decide how many profiles you need.
  • Small, but not too small. If you’re muting a lot, the permission sets are too big; if you need 90 to describe one person, they’re too small.
  • Decide the license when you create the permission set, because a clone can’t change it.
  • A subsystem isn’t finished until its permission sets are. At least read-only, user and admin.
  • A person with two jobs gets two groups, never a copy of both.
  • Wait for Updated before you change a group again.
  • Set the time zone on purpose for every expiring assignment.
  • Temporary admin access needs a person and a process, because the feature won’t time it out.
  • Never put a session-based permission set in an ordinary group. The group decides.
  • Catch today’s users up by hand, then let the policy keep tomorrow’s right.
  • Design the way out as carefully as the way in.
  • After a policy revokes access, check the licenses too.
  • Delegation only adds. Don’t give a delegated admin broad permissions that undo the fence.

Words to Know

Section titled “Words to Know”
TermIn one line
ProfileA user’s one set of baseline settings: the door and the defaults
Minimum Access - SalesforceThe standard profile to start from, with as little as possible turned on
Permission setA bundle of permissions for one task; a user can have many
Standard permission setOne that comes with a feature and a permission set license; you can’t edit it
Permission set groupA bundle of permission sets for one kind of user
Muting permission setThe one set inside a group that turns permissions off for the group’s members
Combined permissionsA group’s view of everything its permission sets give
Assignment expirationAn end date and time on a permission set or group assignment
Session-based permission setOne that’s assigned but inactive until activated for a session
User access policyA rule that grants or revokes access for users who match its criteria
User licenseThe one license every user has: the ring of keys
Permission set licenseAn add-on license that unlocks more permissions: extra keys
Delegated administrationLimited admin rights for non-admins, over chosen roles, profiles and permission sets
User Access SummaryView Summary on a user: their permission sets, groups, public groups and queues

Check Yourself

Section titled “Check Yourself”

Short scenarios in the style of the course. Decide your answer before you open it.

1. An org has a profile for every job title: Sales Rep, Senior Sales Rep, Sales Manager and so on, all with the same license, the same login rules and the same defaults. What would you recommend?

One profile for all of them, because they come in the same way: same license, same door, same defaults. The differences between the jobs move into permission sets, bundled into a permission set group for each persona. Move the access first, then merge the profiles as their own project. Reread How many profiles do you need?

2. Some users need to read airport records, and some need to read both airports and navigational aids. One permission set or two?

Two: View Airports and View Navigational Aids. They’re given apart, so split them. If two permissions are always given together, keep them in one. Reread Small, but not too small.

3. A group's members need everything in one of its permission sets except Delete on Accounts, and another group uses the same permission set with Delete. What do you do?

Add a muting permission set to the first group and mute Delete on Accounts. The permission set doesn’t change, so the other group keeps Delete. Remember that a user who gets Delete another way still has it. Reread The mute button.

4. An admin edits three permission sets in one group, one after another, and gets an error on the second. Why?

The group was still recalculating from the first change. While its status is Updating, you can’t edit the group or change who’s assigned. Wait for Updated. Reread Groups are calculated.

5. Someone covers for the office admin for two weeks and needs Manage Users. Can you give it with an expiration date?

No. A permission set or group with Manage Users, Assign Permission Set, Manage Profiles or Permission Sets can’t have an expiration date. Use a process instead: who approves it, who removes it, and who checks it was removed. Reread The most powerful access can’t expire.

6. A session-based permission set for runways is added to the Pilot group. What happens?

Every pilot in the group can see runways all the time: a session-based permission set inside an ordinary group needs no activation. To keep the access asleep, make the group session-based, or keep the permission set out of the group. Reread The trap: a sleeping set in an awake group.

7. You activate a user access policy for everyone in the Pilot role. A week later, the pilots you already had still don't have the Pilot group. Why?

An active policy applies to existing users only when their record changes to match. The pilots who already matched weren’t touched. Run the policy once by hand for them, then let the active policy handle new and changed users. Reread The catch: active policies wait for a change.

8. A permission set with Read on contracts can't be assigned to a user. The permission set looks right. What would you check?

The user’s licenses. A permission can only be given if the user’s license, or a permission set license, holds the key for it; a Chatter Free user can’t get Read on contracts, for example. Reread Locks and rings of keys.

Explore

Section titled “Explore”

The official list of objectives and their weights. Always check the current version before you book an exam.