Salesforce access design is easiest to understand when administrators stop treating a profile as a complete job description. A user has one profile, but the practical access model is layered: organization-wide defaults and sharing determine which records are reachable, while profiles, permission sets, permission set groups, object permissions, field permissions, and other settings determine what the user can do with those records. The current Salesforce Platform Administrator<\/a> scope expects administrators to reason across those layers rather than memorize a list of checkboxes.<\/p>\n Salesforce also changed an important direction in 2026. The planned retirement of permissions in profiles was cancelled, so profile-based permissions remain supported. At the same time, Salesforce continues to recommend a permission-set-led model for scalable, least-privilege access. That distinction matters for both real administration and certification scenarios. The broader Salesforce certifications<\/a> ecosystem rewards the same habit: use the simplest control that expresses the business need without granting more access than required.<\/p>\n An administrator can test this separation with a concrete example. Suppose a support user can open the Account object but sees only accounts owned by a regional team. Object permission explains why Account is available at all; sharing explains why only a subset appears; field-level security explains why a credit field may still be hidden. Writing those three answers separately prevents the common mistake of trying to solve a record-visibility problem with a permission set or trying to solve an object-permission problem with a sharing rule.<\/p>\n An access question usually contains three different questions. First, who is the user and what baseline settings follow that identity? Second, what objects, fields, applications, classes, or features can that user use? Third, which individual records can the user actually see or edit? Mixing those questions is the fastest way to create a confusing security model.<\/p>\n Profiles and permission sets mainly answer the capability question. Record access comes from organization-wide defaults, role hierarchy, sharing rules, teams, territories, manual sharing, and other mechanisms. A user can have object-level Read access to Opportunities and still be unable to see a particular opportunity because record sharing does not expose it. Conversely, sharing a record cannot override the absence of object permission.<\/p>\n This is why the logic in dynamic access control<\/a> is a useful mental comparison. Access should be assembled from explicit conditions and responsibilities, not from the assumption that one broad role should unlock everything. Salesforce implements that idea through several controls with different scopes.<\/p>\n Baseline design also affects offboarding and role changes. When most access is embedded in a highly permissive profile, changing a person’s responsibilities can require profile swaps that also alter page layouts, record types, login settings, and unrelated permissions. A lean profile reduces that blast radius. The administrator can change modular assignments while preserving the user’s core experience. That makes access changes easier to review, easier to automate from identity governance systems, and less likely to introduce an unrelated configuration change.<\/p>\n Every Salesforce user is assigned exactly one profile. The profile establishes default settings such as assigned applications, default record types, page layout mappings, login hours, login IP ranges, and other baseline behavior. Profiles can still contain object, field, and user permissions, but Salesforce recommends using permission sets and permission set groups for most additive access because those components are reusable and easier to compose.<\/p>\n That recommendation does not make profiles obsolete. Some settings are still profile-centric, and page layout assignment remains tied to the profile and record type combination. An administrator who tries to eliminate profiles conceptually will misread how the platform works. The better design is to keep profiles comparatively lean: define the user’s baseline experience and constraints there, then add capabilities through reusable permission sets.<\/p>\n Security baselines work best when they are stable. A profile named for a narrow project team often becomes difficult to maintain because the team changes faster than the profile. A smaller set of baseline profiles paired with modular permission sets makes organizational changes less disruptive.<\/p>\n Permission sets are especially useful for temporary or cross-functional responsibilities. A user helping with quarter-end forecasting may need a reporting or edit capability for two weeks without becoming a permanent member of another department’s profile. Assigning a focused permission set creates a clearer audit trail than cloning a profile for a short-lived exception. If the organization uses expiration or entitlement workflows, the permission can be removed predictably when the temporary responsibility ends.<\/p>\n A permission set can grant additional object access, field permissions, user permissions, Apex class access, Visualforce access, app or tab access, and other capabilities. A user can receive multiple permission sets, so administrators can model responsibilities as building blocks. Someone in finance might receive a finance permission set; a temporary project lead might receive an approval permission set; an integration user can receive only the API and object capabilities required by the integration.<\/p>\n This additive behavior is central to safe design. Permission sets generally grant access; they are not primarily a way to subtract permissions that a broad profile already grants. If the baseline profile is too permissive, adding more layers does not repair the underlying exposure. Least privilege therefore starts with a sensible baseline and adds only the capabilities that are justified.<\/p>\n The same principle appears in password policy design<\/a>: a control is stronger when its default state is conservative and exceptions are deliberate. Salesforce permissions benefit from the same discipline.<\/p>\n Permission set groups can also reveal poor access modeling. If every group contains dozens of one-off permission sets with overlapping capabilities, the organization may have encoded history rather than job functions. Review groups from the user’s work outward: what tasks does this role perform, which permissions are truly shared, and which privileges are exceptional? Muting permissions can refine a group, but the preferred design is still understandable composition rather than a maze that only one administrator can explain.<\/p>\n Permission set groups bundle several permission sets into an assignable collection. This lets an organization keep individual permission sets focused while giving administrators a practical unit that maps to a job function. A customer service agent group could combine case management, knowledge, telephony, and reporting permissions, while the underlying permission sets remain independently reusable elsewhere.<\/p>\n Groups also make access review easier because the administrator can ask whether a user should have the customer-service bundle rather than manually comparing dozens of individual permissions. When one component changes, the organization updates the permission set and the group benefits from the change.<\/p>\n Large organizations should still document why each permission set exists. A group made from poorly named, overlapping permission sets becomes another form of complexity. Clear ownership, purpose, and retirement criteria turn permission sets into an access architecture instead of a pile of exceptions.<\/p>\n Field security should be validated from multiple interfaces. A page-layout test may look correct while a report, list view, API query, or custom component exposes the same field because the user still has field permission. Conversely, removing field access can break automation, integrations, or reports that depend on the field. Before changing sensitive fields, identify both human and system consumers so the security improvement does not silently break a business process.<\/p>\n Object permissions determine whether a user can create, read, edit, delete, view all, or modify all records for an object. Field-level security then determines which fields are visible or editable. A user might have Edit access to Account records but be unable to edit a sensitive credit-rating field. That is a stronger security boundary than simply removing the field from a page layout.<\/p>\n Page layouts shape the interface, but they are not a substitute for field-level security. A field that is absent from one layout can still be exposed through another interface, report, API, or custom component if the user has permission. Administrators should use field permissions when the requirement is truly about data access and use layouts when the requirement is about usability.<\/p>\n This distinction mirrors the security lesson in permissions management in other enterprise platforms<\/a>: interface configuration and authorization are related, but they are not the same control.<\/p>\n Least privilege should include administrative permissions as well as business data. Capabilities such as Customize Application, Manage Users, Manage Profiles and Permission Sets, or broad data permissions can allow someone to change the security model itself. Separate administrators by responsibility where practical, and monitor powerful assignments. A user who can grant permissions to others effectively has a different risk profile from a user who only edits business records, even if both are called administrators.<\/p>\n Least privilege means a user receives the minimum access necessary for the current responsibility, for the necessary duration. That requires more than selecting conservative checkboxes. Administrators need to understand what a permission enables, what data becomes reachable through that permission, and whether an alternate workflow can satisfy the business need with less exposure.<\/p>\n High-risk permissions deserve special scrutiny. Broad administrative capabilities, Modify All Data, View All Data, password-management rights, and powerful setup permissions can bypass ordinary record-level controls. Integration accounts and automation users also require careful design because their permissions may be exercised continuously rather than only when a human is present.<\/p>\n Strong authentication complements authorization rather than replacing it. Multi-factor authentication<\/a> helps prove who is signing in; permission design determines what that identity can do after authentication succeeds.<\/p>\n Automated provisioning needs reconciliation because identity and application state can drift. If a directory group is removed but a manual Salesforce permission set remains, the user’s effective access no longer matches the source identity model. Periodic comparisons between expected entitlements and actual assignments can catch those exceptions. The same process should look for disabled users, service accounts, and integration identities whose permissions outlived the system or project that originally required them.<\/p>\n Single sign-on can centralize authentication and improve lifecycle control, but an SSO assertion that successfully identifies a user does not answer whether that user should receive access to sensitive Salesforce data. Identity providers, automated provisioning, and Salesforce permission assignment need a shared model of job function, employment state, and approved exceptions.<\/p>\n Organizations often fail at the handoff between identity governance and application authorization. A user changes departments, the identity provider updates the group, but an old Salesforce permission set remains assigned manually. That stale access can persist for months unless the organization has reconciliation and review processes.<\/p>\nStart by separating identity, capability, and record visibility<\/h3>\n
Profiles remain the baseline for every user<\/h3>\n
Permission sets add access without forcing profile proliferation<\/h3>\n
Permission set groups model job functions without recreating giant profiles<\/h3>\n
Object permissions and field-level security solve different problems<\/h3>\n
Permission boundaries should be designed around least privilege<\/h3>\n
SSO and identity provisioning do not automatically create good authorization<\/h3>\n