12 Salesforce Security Interview Questions on Sharing Models

Strong answer

Private establishes the most restrictive default for users who do not own a record. It does not mean “only the owner can ever see it.” Access can still come from the role hierarchy, sharing rules, teams, territories, manual sharing, implicit sharing, programmatic sharing, or broad permissions such as View All and Modify All.

I would choose OWD from the most restrictive legitimate baseline and then open access deliberately. If only sales representatives and their management chain should see Opportunities by default, Private is a sensible starting point. Cross-functional access for Deal Desk should then have an explicit, reviewable grant rather than a more permissive OWD for everyone.

The trade-off is operational complexity. A restrictive baseline usually creates more share records, calculations, and troubleshooting paths. I would not make OWD Private merely because it sounds secure; I would derive it from the access matrix, expected data volume, sharing mechanisms, and support model.

Strong answer

Not automatically. The role hierarchy is a record-access structure, not a directory of reporting lines. I model roles around who must see records owned by whom. If two management layers need identical record visibility, duplicating both layers as roles adds maintenance without improving security.

I would ask whether managers should inherit access to records owned by or shared with users below them. If yes, roles can express that upward visibility. If access must move sideways across functions or regions, a sharing rule, team, territory, or public group is usually clearer than distorting the hierarchy.

For custom objects I also check the Grant Access Using Hierarchies setting. Standard-object and custom-object behavior is not identical, so I would verify the object’s configuration rather than reciting “managers always see everything.”

Strong answer

I separate the two objects. For Opportunities, Private OWD plus a role hierarchy that matches regional ownership can provide the required management visibility. For the confidential custom object, I evaluate disabling Grant Access Using Hierarchies, then grant access only to approved users through a tightly governed mechanism.

I would not solve both requirements with one oversized role tree. The hierarchy may be correct for sales records and wrong for legal, investigation, or compensation data. Object-specific OWD and hierarchy behavior let the model reflect those differences.

I would also check object-level View All, Modify All, and Modify All Data. Disabling hierarchical access on a custom object does not neutralize broad administrative permissions.

Strong answer

I use an owner-based rule when access follows who owns the record. For example, Accounts owned by the APAC Sales role and subordinates can be shared read-only with an APAC Finance public group. I use a criteria-based rule when access follows record data, such as Opportunities where Requires_Legal_Review__c = true being shared with the Legal Reviewers group.

I prefer the most stable driver. Ownership works well when the ownership model is trustworthy; business criteria work well when a governed field represents the access decision. A text field that users can freely edit is a weak security control, so I would restrict edits, automate its value, or choose a stronger criterion.

Both rule types grant wider access; they do not deny access supplied by OWD or another path. If multiple grants apply, effective access can be more permissive than the access level on the rule being inspected.

Strong answer

A public group gives the sharing rule a stable business audience. The rule can share eligible records to Deal_Desk_Reviewers, while administrators manage membership separately. That is easier to explain and audit than duplicating similar rules for individual users.

The group itself does not grant record access. It becomes an access path only when a sharing rule, manual share, folder permission, queue, or another feature references it. I name groups by purpose, document their owner, review nested membership, and avoid using them as an unmanaged substitute for identity governance.

At scale, I consider membership churn and calculation cost. A heavily nested group referenced by many rules can make role or membership changes expensive. I remove redundant paths and test large changes in a representative sandbox.

Strong answer

I use a team when named collaborators have a business relationship to selected records—for example, an account executive, solution engineer, and renewal manager collaborating on one Account or Opportunity. A team makes the participants and their role in the work visible.

Manual sharing is appropriate for a genuine one-off exception, such as giving a specialist access to a single Case. It is not a scalable entitlement process. I would ask who can create and revoke the share, what happens on ownership transfer, and how support teams will find stale exceptions.

A sharing rule is better when the same condition applies repeatedly. If every strategic Opportunity needs Legal access, relying on record owners to remember a manual share is both fragile and hard to audit.

Strong answer

No. Roles and territories answer different access questions. The role hierarchy usually follows ownership and management visibility. Enterprise Territory Management can express a market assignment that cuts across owners—for example, geography, industry, or named-account coverage.

I would first confirm that the requirement needs territory behavior rather than a small number of sharing rules. Territory management introduces assignment rules, model activation, forecasting implications, and a second hierarchy to operate. It is valuable when territory membership and account coverage are real business concepts, but excessive for a simple exception.

The design must show how role-derived and territory-derived access combine. I would test a representative account that belongs to multiple territories, a user who changes territories, and a record with no territory assignment.

Strong answer

No. A sharing rule adds access; it cannot subtract access from OWD, hierarchy, another rule, or a broad permission. I would first find the unwanted grant and remove or narrow it.

For a supported object and a well-defined user population, a restriction rule can filter records the user would otherwise be able to see through sharing. For example, a contractor group may be limited to Tasks for an approved region even if another sharing path exposes more Tasks.

I would verify object support, edition, user criteria, record criteria, other active restriction rules, API and application behavior, and the effect on search, list views, reports, lookups, and automation. A restriction rule is a targeted filter, not a replacement for correct OWD, object permissions, or field security.

Strong answer

Not necessarily. Record sharing answers which records a user can access. Object permissions answer what operations are allowed on that object, and field-level security answers which fields can be read or edited. Page layouts control presentation but are not a security boundary.

I troubleshoot the symptom at the right layer. If the record does not open, I start with object Read and record access. If the record opens but one field is absent, I inspect field permissions from the profile, permission sets, and permission set groups. If the field is visible but cannot be edited, I check field Edit, object Edit, record edit access, record locking, validation, and business automation.

I avoid granting View All or Modify All just to make a field visible. Those permissions widen record access and do not replace correct field-level security.

Strong answer

I treat external access as a separate threat model. I begin with the external OWD, the exact Experience Cloud license, whether the license participates in roles, and whether the access pattern should use partner roles, sharing sets, share groups, account relationships, or other supported mechanisms.

I do not assume an internal sharing rule is safe for external audiences. I inspect whether its target includes portal subordinates and test with real external personas. High-volume users do not participate in the full role-based sharing model in the same way as partner users, so license choice affects architecture.

For unauthenticated guests, I use private-by-default access and explicit guest-user sharing only where the business case requires it. I also review object and field permissions, Apex execution context, file exposure, search behavior, and direct-URL negative tests. “The page does not display the field” is not sufficient evidence.

Strong answer

I use programmatic sharing only when the access requirement is dynamic and cannot be expressed safely with declarative sharing. Examples include a custom assignment engine or an external system that remains the source of truth for access relationships.

The code must manage the full lifecycle: create only the required shares, remain idempotent, update access when the source relationship changes, delete stale shares, handle partial failures, and provide reconciliation. I prefer a named sharing reason where the object and platform capability support it so administrators can understand why the share exists and automation can manage only its own rows.

I also separate the act of creating a share from Apex execution context. with sharing controls whether a class respects record sharing during access; it does not automatically enforce object and field permissions, and it does not by itself design a correct sharing lifecycle.

Strong answer

I preserve the evidence before changing configuration: user, record, object, required versus observed access, channel, time, and whether the access is read or edit. Then I inspect layers from broadest to most specific.

1. Confirm the user’s license and object permissions, especially View All, Modify All, and Modify All Data.
2. Confirm the record owner, queue owner, and OWD for the correct internal or external audience.
3. Check the user’s role relative to the owner and the object’s hierarchy behavior.
4. Inspect owner-based and criteria-based sharing rules, including public-group membership.
5. Inspect teams, territories, manual shares, implicit parent access, and programmatic shares.
6. Check restriction rules when the problem is missing or unexpectedly filtered visibility.
7. Check whether custom Apex or an integration runs in privileged context and exposes the data through another channel.

I use User Access Summary to trace permission sources, and Sharing Hierarchy on the record where available to inspect record access. Then I reproduce the behavior with the affected user or an equivalent least-privileged test persona. Removing the first visible share is not enough; another path may still grant equal or greater access.