Salesforce security is easiest to understand when access is treated as layers. Object and field permissions answer what a user can do in principle; organization-wide defaults set the baseline for records the user does not own; the role hierarchy, sharing rules, teams, territories, and manual sharing can then open record access where the business requires it. The current Salesforce Platform Administrator exam expects administrators to reason about these layers rather than solve every access request by giving broader permissions.
The official credential is now presented as Salesforce Certified Platform Administrator, while the approved internal inventory retains the familiar adm-201 destination. The wider Salesforce certifications ecosystem includes developer and analyst roles, but administrators are the people who often have to convert a sentence such as “regional managers need to see their teams’ accounts, but not other regions” into a maintainable sharing model.
object access and record access are different questions
A user can have permission to read the Account object and still be unable to see a specific account record. Profiles, permission sets, and permission set groups establish baseline object, field, and feature permissions. Record-level sharing then determines which individual records are visible within that allowed object scope.
This distinction prevents a common troubleshooting mistake. If a user cannot see one record but can see others of the same object, granting more object permissions may not solve the problem. The administrator should investigate ownership, organization-wide defaults, role hierarchy, sharing rules, teams, territories, or manual sharing.
Salesforce currently recommends using permission sets and permission set groups to manage many user permissions, while profiles provide default settings. Roles primarily influence record visibility rather than replacing profiles or permission sets.
Field-level security and record sharing can interact in ways that confuse users. A user may have access to a record but still be unable to see a sensitive field on it. Administrators should avoid describing the sharing model as if record visibility automatically implies full field visibility.
organization-wide defaults define the most restrictive baseline
Organization-wide defaults, or OWD, specify how users can access records they do not own before other sharing mechanisms expand visibility. Common options include Private, Public Read Only, Public Read/Write, and Controlled by Parent depending on the object. A strong design starts with the access required by the most restricted legitimate user.
The principle is to lock down first and open up selectively. If an object is set to Public Read/Write, a sharing rule cannot make a subset of those records private. Sharing mechanisms generally grant more access; they do not subtract access already granted by OWD or object permissions.
This “baseline then exceptions” model is similar to other access-control systems and can be compared with dynamic access-control concepts, though Salesforce implements its own record-sharing architecture.
The same object can use different internal and external organization-wide defaults. That is important for Experience Cloud or partner scenarios where external users should have a more restrictive baseline than employees. External role hierarchies and sharing models deserve separate testing rather than assumptions based on internal behavior.
the role hierarchy is a data-access hierarchy, not necessarily the org chart
Salesforce’s role hierarchy gives users higher in the hierarchy access to records owned by or shared with users below them, subject to object permissions and sharing configuration. It often resembles management reporting lines, but Salesforce explicitly notes that it does not have to mirror the company’s organization chart. A role should represent a level of data access.
That distinction matters in matrixed organizations. Two employees may report to the same executive but require very different record visibility. Creating roles solely to copy job titles can make the hierarchy deep, difficult to maintain, and poorly aligned with actual access needs.
For standard objects, hierarchy behavior is part of the normal sharing model. For custom objects, “Grant Access Using Hierarchies” can be disabled in appropriate configurations, which changes whether managers automatically inherit access.
Role hierarchy depth has operational cost. Large role changes can trigger sharing recalculation, and excessively granular hierarchies are harder to reason about. Administrators should consolidate roles when users genuinely require the same record access rather than creating one role for every title.
sharing rules create automatic exceptions to restrictive defaults
Sharing rules extend record access to groups of users. Salesforce supports owner-based rules and criteria-based rules. An owner-based rule might share records owned by one role or public group with another group. A criteria-based rule can share records when field values meet defined conditions.
A sharing rule has three essential decisions: which records are shared, with whom, and at what access level. The administrator should model those decisions in business language before opening Setup. “Share all enterprise accounts owned by the East sales group with the National Accounts group as read only” is much safer than “give the national team more access.”
Sharing rules cannot grant edit capability if the user’s object-level permission is read only. Record sharing opens access within the ceiling established by object permissions.
Criteria-based sharing rules depend on field values remaining accurate. If a rule shares cases where Region equals “West,” a bad or stale region value becomes an access-control problem as well as a data-quality problem. Security design therefore depends on trustworthy classification fields.
public groups make sharing designs easier to maintain
Public groups can contain users, roles, roles and subordinates, and other groups. They are useful when access needs cut across the formal role hierarchy. Instead of creating many nearly identical sharing rules for individual users, an administrator can target a group whose membership represents a stable business responsibility.
The maintenance benefit is significant. When a person changes teams, updating group membership can be safer than editing many separate sharing rules. Naming conventions should describe the access purpose rather than a temporary employee list, so future administrators understand why the group exists.
Groups also encourage administrators to separate identity management from policy logic. The sharing rule can stay constant while the set of people fulfilling the role changes.
Public groups can nest, which improves reuse but can make effective membership harder to see. Naming, documentation, and periodic review are essential when groups become part of sensitive sharing rules. An old group should not continue granting access simply because nobody remembers what it controls.
manual sharing and teams handle exceptions that do not justify global rules
Not every exception deserves an org-wide sharing rule. Manual sharing can let a record owner or appropriately privileged user share an individual record. Account teams, opportunity teams, case teams, and territory features provide other structured ways to extend access for particular collaboration patterns.
The administrator’s job is to choose the narrowest mechanism that matches the recurring business need. A one-time collaboration request may be appropriate for manual sharing, while a consistent rule applying to every record in a category belongs in an automatic mechanism.
Too many one-off shares can become difficult to audit, while overly broad sharing rules can expose data unnecessarily. The balance is predictable access with minimal administrative friction.
When access must be temporary, administrators should consider how it will be revoked. Permanent sharing rules are a poor fit for short-lived project access unless the target group is carefully managed. Time-bound access often requires identity or permission governance outside the sharing rule itself.
access troubleshooting should trace the path that granted or denied visibility
When a user unexpectedly has or lacks access, administrators should avoid random permission changes. Confirm object and field permissions, OWD, ownership, role placement, sharing rules, group membership, teams, territories, and manual shares. Salesforce provides tools and record-access details that can help identify why a user can see a record.
The direction of troubleshooting matters. If a user has too much access, adding a restrictive sharing rule will not help because sharing rules only open access. The source may be a broad OWD, a permission such as View All, the role hierarchy, a territory, or another sharing mechanism.
The broader principles in permission and role management apply across platforms: understand the inheritance model before changing permissions.
“View All” and “Modify All” style permissions can override much of the record-sharing model for an object. These permissions are useful for administrators or special operational roles but should be tightly controlled because they bypass the least-privilege logic built through OWD and sharing rules.
reporting and automation must respect the same security model
Record access affects what users see in reports, list views, and many automation contexts. A report folder may be shared with a user, but the report still reflects record access unless the feature uses a different running context. A flow can run in user context or system context depending on its configuration, which can change how sharing is enforced.
This means an administrator should not design record sharing in isolation. Dashboards, integrations, flows, and external users may expose or consume records through different execution contexts. Security testing should use representative users and realistic operations rather than checking only a setup screen.
The adjacent Salesforce Platform Developer destination is useful where automation or custom code influences record access, because programmatic behavior can bypass assumptions made from the user interface alone.
Documentation should capture the intended access model, not only the configuration clicks. A simple matrix showing object, baseline OWD, hierarchy behavior, sharing-rule purpose, and exception mechanisms gives future administrators a map for troubleshooting and audit review.
Sharing design should also account for ownership changes. When records move between users or territories, role-hierarchy and owner-based sharing outcomes can change automatically. A migration that reassigns thousands of records can therefore create a major access change even if no sharing rule is edited. Ownership updates should be reviewed as security events as well as data-maintenance events.
Record access can affect integrations too. An integration user with broad permissions may retrieve data that ordinary users cannot see, which can be appropriate for a trusted system but risky if the downstream application exposes it without equivalent controls. Administrators should document integration identities and avoid assuming that the Salesforce sharing model automatically follows data after it leaves the platform.
Sharing rules should be periodically reviewed against current organizational structure. Teams merge, regions change, and public groups accumulate members. A rule that was least-privilege two years ago can become overly broad without any configuration change if the group or criteria meaning evolves. Access recertification helps detect that silent drift.
When troubleshooting, administrators should capture the reason access was granted rather than only the final answer that a user can see the record. That provenance is valuable during audits and future changes because it identifies the control that must be modified. Otherwise, teams risk removing one path while another hidden path continues to grant the same access.
A useful way to design record access is to separate the baseline from the exceptions on paper before configuring anything. For each object, identify the most restricted user, choose the appropriate organization-wide default, then list the predictable groups that need additional access and the mechanism that should provide it. Role hierarchy, sharing rules, teams, queues, territories, and manual sharing solve different shapes of problem. This sequence makes the model easier to audit because each layer has a reason to exist. Starting with a permissive baseline and trying to remove access later is fundamentally harder, since sharing features are primarily designed to open access rather than claw it back.
Ownership changes can also change visibility in ways that surprise users. When a record moves to a new owner, access inherited through role hierarchy, owner-based sharing rules, account relationships, or team membership can change with it. That is why transfers should be tested with representative users rather than judged only from an administrator account. The same principle applies to reorganizations: moving users between roles can alter access to large sets of records even when object permissions stay unchanged. Before a major role or ownership migration, administrators should document the expected before-and-after access pattern and verify it with real record examples.
Security reviews are stronger when they test both overexposure and unnecessary restriction. One user seeing too much can create confidentiality risk, while another user seeing too little can cause workarounds, duplicate records, or off-platform data sharing. Least privilege therefore means the minimum access required for the business process to function, not the smallest number of records possible. A maintainable Salesforce sharing model expresses that requirement through a small number of understandable rules, clear ownership, and periodic validation instead of accumulating one-off exceptions that nobody can later explain.
Platform Administrator questions reward least privilege and maintainability
For exam scenarios, start with the most restrictive correct OWD and then select the appropriate mechanism to open access. Use the role hierarchy when managerial access should follow data-access hierarchy. Use sharing rules for predictable exceptions affecting groups of records and users. Use manual sharing or teams for narrower collaboration. Avoid broad object permissions when the requirement concerns only certain records.
A useful lab is to create two roles, set a custom object to Private, test visibility, add a user higher in the hierarchy, create a public group, add a criteria-based sharing rule, and verify the result with multiple users. Then change one user’s role and observe how inherited access changes.
The Salesforce Business Analyst perspective can improve these designs because the administrator needs to understand who truly needs access and why. Security works best when technical controls reflect a clear business responsibility rather than a collection of historical exceptions.
A practical security design starts by writing the access requirement in business language before configuring Salesforce. For each major object, identify who owns records, who should normally see only their own records, which managers need inherited visibility, and which peer groups require exceptions. That exercise separates the organizational reporting structure from the data-sharing requirement and reduces the temptation to make the role hierarchy mirror every line on the company org chart.
Administrators should test sharing with representative users rather than relying only on Setup screens. Create or select records owned by users in different branches, log in as or validate access for the affected personas, and confirm read, edit, and transfer behavior. Include records that should remain private. A test that only proves permitted access is incomplete; the stronger test also demonstrates that unauthorized users cannot see or modify the same records.
Changes to organization-wide defaults deserve particular care because they alter the baseline for an entire object. Tightening access can break reports, integrations, queues, or business processes that depended on broader visibility, while opening access can expose data far beyond the intended audience. Before changing an OWD setting, inventory the sharing rules, teams, territories, Apex sharing, and automated processes that rely on the current model, then retest critical workflows after the change.
Sharing architecture should be reviewed as the organization evolves. New business units, acquisitions, regional privacy requirements, and reorganizations can turn an once-simple role tree into a brittle access model. Periodic review of roles and sharing rules helps retire obsolete exceptions and keeps the configuration aligned with current responsibilities rather than preserving years of historical structure.