Salesforce Platform Administrator<\/a>, the modern pattern is clear in current Salesforce guidance: use profiles for baseline\/default settings, use permission sets and permission set groups to grant object, field, user, and feature permissions, and use record-sharing mechanisms for visibility to individual records.<\/p>\nSeparate object, field, and record access<\/h2>\n
Start by asking three different questions. Can the user access this type of data at all? Can the user read or edit this field? Which individual records of that object can the user see or edit? Salesforce uses different controls for those layers because they solve different problems.<\/p>\n
Object permissions answer whether a user can create, read, edit, or delete records of an object. Field permissions narrow that access to specific fields. Record-level sharing decides which rows are visible after the user already has the necessary object permission. A sharing rule cannot grant useful access to an Opportunity if the user has no permission to read the Opportunity object.<\/p>\n
This order prevents a common mistake: troubleshooting every access problem through sharing rules. If a user cannot see the object or field, record sharing is not the layer to fix.<\/p>\n
Use profiles as the baseline, not as a persona factory<\/h2>\n
Every Salesforce user has one profile. Profiles still provide default settings such as assigned apps, record types, page layouts, login constraints, and baseline permissions. But Salesforce recommends using permission sets and permission set groups for managing the permissions users need rather than creating a different profile for every combination of responsibilities.<\/p>\n
Salesforce had previously planned to retire permissions in profiles starting in Spring \u201926, but it canceled that enforcement in June 2026. Profiles therefore continue to support permissions, while Salesforce still recommends a permission-set-led, least-privilege model for scalable access management.<\/p>\n
The older profile-heavy model often grows into dozens of nearly identical profiles: Sales Rep, Senior Sales Rep, Sales Rep Plus Reports, Sales Rep Plus Export, Sales Rep Temporary Campaign Access, and so on. Every policy change then has to be repeated across variants, and it becomes difficult to explain why two users differ.<\/p>\n
A leaner design keeps the profile minimal and stable, then adds access through permission sets that represent capabilities. That makes assignment easier to understand and reduces the number of full-profile clones administrators must maintain.<\/p>\n
Use permission sets for additive capabilities<\/h2>\n
A permission set grants permissions and access settings in addition to the user\u2019s profile. One user can have multiple permission sets, so each set can be designed around a finite task or responsibility. For example, \u201cManage Contracts,\u201d \u201cExport Reports,\u201d or \u201cApprove Discounts\u201d is easier to reason about than a profile that bundles every possible capability for one department.<\/p>\n
This additive model supports least privilege because administrators can start with a small baseline and grant only the extra functions each user needs. It also supports temporary access. A user who joins a project for three months can receive a project-specific permission set and have it removed later without changing the person\u2019s core profile.<\/p>\n
Permission sets are not a substitute for record sharing. Granting Edit on the Case object means the user may edit Case records they can access; it does not automatically make every Case visible.<\/p>\n
Use permission set groups to assemble job personas<\/h2>\n
Permission set groups bundle multiple permission sets so they can be assigned as one unit. This lets administrators build reusable capabilities first and then compose them into personas. A Sales Operations group might contain permission sets for opportunity administration, quote support, reporting, and data import. A Regional Manager group might combine reporting, forecasting, and approval capabilities.<\/p>\n
The group reduces assignment complexity without giving up modularity. If one capability changes, update the underlying permission set and every group using it can inherit the updated permission structure. That is much easier to manage than editing several unrelated profiles.<\/p>\n
Permission set groups also support a clearer access review. Instead of asking why a user has 150 individual permissions, reviewers can see that the user belongs to a job-related group composed of defined capabilities and then drill into the group when necessary.<\/p>\n
License boundaries matter as well. A permission set cannot grant a capability that the user\u2019s license does not support. When an assignment fails or a permission appears unavailable, confirm the license before redesigning the security model. Permission set groups inherit the same underlying constraint: grouping several permission sets does not bypass licensing.<\/p>\n
Muting and group composition should also be documented when used. A permission set group represents the effective combination of its component permission sets, so a reviewer needs to understand both the capabilities contributed by the components and any intentionally muted permissions. Treat the group as a managed persona, not simply a folder.<\/p>\n
Org-wide defaults set the record-sharing baseline<\/h2>\n
After object and field permissions are established, organization-wide defaults (OWD) determine the baseline record visibility for records users do not own. The principle is to set the baseline as restrictive as the business requires and then open access using other sharing features.<\/p>\n
If Opportunity OWD is private, a salesperson does not automatically see another salesperson\u2019s opportunities simply because both users have Read permission on the Opportunity object. Additional record access can come from role hierarchy, sharing rules, teams, manual sharing, territory mechanisms, or other supported features depending on the use case.<\/p>\n
This \u201clock down, then open\u201d design is easier to reason about than making everything public and trying to subtract visibility later. Many Salesforce sharing features are designed to grant additional access, not to make an already broad OWD stricter.<\/p>\n
Roles and sharing rules solve different record-visibility patterns<\/h2>\n
Role hierarchy commonly supports management visibility. Users higher in the hierarchy can receive access to records owned by or shared with users below them, subject to object behavior and configuration. The hierarchy is about data access relationships, not a direct copy of an HR org chart.<\/p>\n
Sharing rules create automatic exceptions for groups of users. Ownership-based rules can share records owned by one set of users with another. Criteria-based rules can share records whose field values match defined conditions. They are useful when access should be systematic rather than manually granted record by record.<\/p>\n
Manual sharing handles exceptions that do not fit a repeatable rule. It can be valuable, but a large volume of manual shares usually signals that the access model should be redesigned around a more durable rule or team structure.<\/p>\n
Design permissions around least privilege and explainability<\/h2>\n
An access model is healthy when an administrator can answer \u201cWhy can this user do this?\u201d without guessing. Start with the user\u2019s profile and assigned permission sets or groups for object, field, and feature permissions. Then trace record access through ownership, OWD, role hierarchy, sharing rules, teams, or manual sharing.<\/p>\n
Do not grant broad system permissions simply to resolve one access ticket. Permissions such as Modify All or broad administrative capabilities can bypass carefully designed record restrictions. If a user only needs to edit one object or perform one task, grant that capability directly rather than using an oversized administrative permission as a shortcut.<\/p>\n
Periodic access reviews should look for permission sets nobody understands, users who accumulated temporary access, groups with overlapping responsibilities, and sharing rules that no longer match the business. Least privilege is a lifecycle, not a one-time configuration.<\/p>\n
Troubleshoot access layer by layer<\/h2>\n
When a user reports \u201cI can\u2019t access this,\u201d identify the exact failure. Is the object missing from the app? Can the user open the object but not the record? Is the record visible but one field hidden? Can the field be read but not edited? Can the user edit through the UI but an automation fails under a different running context?<\/p>\n
Then test the layers in order. Confirm license and profile baseline, permission sets and groups, object permission, field permission, record ownership and OWD, role or territory behavior, sharing rules, and any special access mechanisms. Salesforce access summary features can help reveal which configuration granted a permission or record relationship.<\/p>\n
This structured approach prevents \u201cfixes\u201d that solve one symptom by over-permissioning the user. It also creates better documentation because the final access path is intentional rather than accidental.<\/p>\n
For example, assume an analyst can open Accounts but cannot see the Annual Revenue field. The first instinct should not be to add a sharing rule, because the record is already visible. The problem is field-level permission. In a different case, the analyst can see Annual Revenue on one account but not another account at all; then the investigation moves to record ownership, OWD, hierarchy, and sharing. Naming the missing layer before changing configuration is one of the most effective ways to avoid over-granting access.<\/p>\n
Build a permission architecture from capabilities plus sharing<\/h2>\n
A durable Salesforce model has two complementary halves. Permission sets and permission set groups describe what a person is allowed to do with objects, fields, and platform capabilities. Record sharing describes which specific records the person can reach. Profiles provide the necessary baseline\/default context without carrying every persona variation.<\/p>\n
That separation keeps the Salesforce<\/a> security model understandable as teams grow. New roles can be assembled from existing capability sets, record access can change with ownership and organizational relationships, and administrators can investigate access without maintaining a maze of near-duplicate profiles.<\/p>\n","protected":false},"excerpt":{"rendered":"Salesforce access control is layered. A user can have permission to open an object but still be unable to see a particular record. A user […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[29,38,162,53],"tags":[],"class_list":["post-3313","post","type-post","status-publish","format-standard","hentry","category-certifications","category-enterprise-platforms","category-exam-platform-administrator","category-salesforce-certifications"],"_links":{"self":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts\/3313","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/comments?post=3313"}],"version-history":[{"count":1,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts\/3313\/revisions"}],"predecessor-version":[{"id":3814,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts\/3313\/revisions\/3814"}],"wp:attachment":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/media?parent=3313"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/categories?post=3313"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/tags?post=3313"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}