Salesforce Sharing and Visibility Interview Questions

I describe it as a series of gates, and access is granted if any one of them opens.

1. Ownership: The record owner has access, subject to object permissions.
2. Organization-wide defaults: The OWD is the baseline for everyone who is not the owner. It is the floor, and everything else only opens access further.
3. Role hierarchy: Users above the owner in the hierarchy inherit access, unless Grant Access Using Hierarchies has been deselected — which is only possible on custom objects.
4. Sharing rules: Ownership-based or criteria-based, granting to public groups, roles, roles and subordinates, or territories.
5. Teams: Account, opportunity, and case teams grant per-record access with a defined access level.
6. Manual and programmatic shares: Manual shares, and Apex managed shares written to the object's share table.
7. Implicit sharing: Platform-generated grants, most importantly read access to a parent Account when you can see a child Case, Contact, or Opportunity.
8. View All and Modify All: Object permissions that bypass all of the above for that object, and View All Data / Modify All Data which bypass it for every object.

Then I add the two things that sit outside the additive model: restriction rules, which subtract from whatever the above granted, and object and field permissions, which gate access before record sharing is even consulted.

They are three independent layers, and a user needs all three to see data.

1. Object permissions decide whether the user can touch the object at all — Create, Read, Edit, Delete, plus View All and Modify All. Granted on profiles and permission sets.
2. Field-level security decides which fields of that object the user can read or edit. Also on profiles and permission sets, and enforced through the UI, reports, search, and the API.
3. Record-level sharing decides which rows the user sees, through the mechanisms in the sharing model.

In practice object permissions are evaluated first — no Read on Case means no cases regardless of sharing — then record access determines the row set, then FLS determines which columns come back.

The distinction I stress in design reviews is that page layouts are not in this list. A field removed from a layout is still returned by the API and by reports. If a field must be hidden, it has to be hidden with field-level security.

I describe the OWD as the answer to the question: what should someone see who has no other relationship to this record? Everything else in the sharing model only ever opens access further, so the OWD is the floor and it should be set to the most restrictive value the business can tolerate.

The main choices are Private, Public Read Only, Public Read/Write, and Controlled by Parent for child objects whose access follows a parent. Some objects add their own values — Public Read/Write/Transfer on Leads and Cases, Public Full Access on Campaign, and a separate set of levels on Price Book — so it is worth checking the specific object rather than assuming a universal list. There is also a separate external default that governs external users and cannot be less restrictive than the internal one.

My working method is to start at Private for anything sensitive and then justify every relaxation with a concrete requirement. That is not just caution — it is easier to open access later than to tighten it, because tightening an OWD on a large object triggers a full sharing recalculation and usually breaks something that had quietly come to depend on the loose setting.

I explain that sharing rules only grant, never revoke — there is no access level of None — and then I redirect the conversation to diagnosis, because the useful question is what is granting the access today.

1. If it is the organization-wide default, the fix is to tighten it and add rules for the populations that legitimately need access.
2. If it is the role hierarchy, and the object is custom, deselecting Grant Access Using Hierarchies may be right. On a standard object that option does not exist, so the answer is usually to restructure the hierarchy or accept it.
3. If it is an existing sharing rule or team, remove or narrow that rule.
4. If access must be subtracted while other legitimate grants stay in place, a restriction rule is the mechanism designed for it.
5. If it is View All Data or Modify All Data, no sharing configuration will help — those permissions have to go.

I use the record's Sharing action, the Sharing Hierarchy view, and a query on the share table to establish which of these it actually is, rather than guessing.

Implicit sharing is access the platform generates itself, without any rule you configured.

1. Parent implicit sharing: A user who gains access to a Case, Contact, or Opportunity automatically receives read access to the parent Account. It is read-only and it covers only the parent, not the parent's other children.
2. Child implicit sharing: The Account owner may gain access to child Contacts, Opportunities, and Cases owned by others — but only to the level set by the Contact Access, Opportunity Access, and Case Access settings on their role.

It matters for two reasons. First, it is the explanation for a whole category of confusing tickets — an account owner who cannot see opportunities on their own account almost always has a role-level access setting at No Access, and no amount of Opportunity sharing rule tuning will fix it.

Second, implicit share rows are generated in volume. In a large org they can dominate the sharing tables, which drives recalculation duration when you change an OWD or reorganise roles.

I would set the Opportunity organization-wide default to Private, which gives reps their own records. The role hierarchy then covers the managers automatically — that is precisely what it exists for, and it needs no configuration beyond a correct hierarchy.

For the deal desk I would ask how many people and how stable the population is. For a small, stable group I would grant View All on Opportunity through a dedicated permission set. It is one object-scoped permission rather than a sharing rule that has to be maintained, and it is honest about what is being granted.

I would specifically avoid two things: putting the deal desk at the top of the role hierarchy, which grants far more than opportunities and distorts forecasting, and granting View All Data, which is org-wide and unnecessary.

I would also ask whether opportunity teams are needed for the supporting cast — sales engineers, legal — because that is a per-record requirement the hierarchy cannot express.

I reach for Apex managed sharing only when the access rule cannot be expressed as a function of record data or ownership. The typical triggers are access that depends on data on a related record, on the result of an external lookup, or on a relationship that has no field on the record being shared.

Mechanically it means inserting rows into the object's __Share table with ParentId, UserOrGroupId, AccessLevel, and a RowCause set to a custom Apex sharing reason defined on the custom object. Using a custom reason matters: shares with RowCause Manual are deleted when ownership changes, whereas shares with a custom reason survive and can be recalculated in bulk by an Apex sharing recalculation class.

The cost is real. You own the recalculation logic, the bulkification, the test coverage, and the failure modes — a share that silently fails to insert is an access bug nobody notices until an audit. Custom Apex sharing reasons are also available for custom objects only.

So my rule is: try to normalise the requirement into a classification field first. If a formula or a small set of derived values can drive declarative rules, that is almost always the better long-term answer.

They move in opposite directions.

A sharing rule is additive. It grants access to a population — a public group, role, role and subordinates, or territory — either based on record ownership or on field criteria. It can never take access away.

A restriction rule is subtractive. It defines a filter on an object for a set of users, and records that fail the filter become invisible to them even if ownership, hierarchy, a sharing rule, or a team would otherwise grant access.

I use sharing rules for the normal case: a restrictive baseline opened up for the populations that need it. I use restriction rules when a genuine exclusion is required on top of grants I cannot or should not remove — typically a confidentiality or regulatory carve-out, like contractors who must never see records under litigation hold.

Restriction rules are supported on a defined set of objects rather than universally, so I check current object support before committing to a design that depends on them.

The first question is always which license, because it determines which mechanisms are even available.

1. Customer Community is a high-volume license. Those users have no role, cannot be referenced in sharing rules, and cannot be added to the role hierarchy. Access comes from sharing sets, which grant records by matching a field on the record to the user's related Account or Contact. Internal users get access to records those external users own through a share group on the sharing set.
2. Customer Community Plus and Partner Community are role-based. Each external account gets an account role hierarchy, records roll up within that partner or customer account, and those users can be used in sharing rules and public groups.

There is also a separate external organization-wide default per object, which cannot be less restrictive than the internal one.

The architectural trap is choosing the license on cost and discovering the sharing constraint afterwards. A design that assumes tens of thousands of external users each participating in sharing rules is describing a role-based license at a scale and cost that usually was not budgeted.

Under the secure guest user access model, the guest user's organization-wide default is forced to Private and cannot be raised, and the guest user cannot own records.

Access to public data is granted through guest user sharing rules, which grant Read only. Guest users cannot be added to public groups, queues, teams, or ordinary sharing rules, and they cannot be given manual shares.

In design terms this means public data has to be a deliberate, enumerated set. I would model the publicly readable records as a distinct object or a clearly flagged subset, write a guest user sharing rule scoped to exactly that set, and then review it as a security artefact rather than as a convenience setting.

I would also note that guest user sharing rules count against the object's criteria-based sharing rule allocation, and that anything the guest user can reach should be assumed to be fully public, because it is.

Two types matter for sharing, and they have different remedies.

1. Ownership skew: One user owns a very large number of records — commonly an integration user or a placeholder. Because the role hierarchy grants access upward, any change to that user's role, or to the hierarchy above them, forces recalculation across all of those records. The remedies are to distribute ownership across many users, or to move the owning user outside the role hierarchy so there is no upward path to recalculate.
2. Account or lookup data skew: Very many child records under one parent, conventionally described as more than roughly ten thousand. The platform locks the parent during child DML and maintains implicit shares for the children, producing row-lock errors and slow recalculation. The remedy is to distribute the children across a set of bucket parent records.

The diagnostic habit I would want to demonstrate is separating them by symptom. Lock errors during a bulk child load point at parent skew. Slow recalculation after a role change points at ownership skew.

Volume changes the cost of every sharing decision, so I plan for recalculation as a first-class concern.

1. Treat OWD changes as a project, not a setting. Tightening an OWD on a large object triggers a full recalculation that can run for hours, during which access is inconsistent. It gets a maintenance window, a full-copy sandbox rehearsal to measure duration, and the compensating sharing rules prepared in advance.
2. Batch role and group membership changes rather than trickling them through, because each one invalidates portions of the sharing tables.
3. Use deferred sharing calculation for large loads and migrations. Salesforce Support enables it; you suspend recalculation, load, then resume and recalculate once.
4. Keep the role hierarchy as flat as the access requirements allow, since every level multiplies the share rows maintained.
5. Watch for skew proactively rather than discovering it through lock errors.
6. Sort bulk load batches by parent Id so concurrent batches do not contend for the same parent lock.

I would also budget for the fact that implicit sharing rows can dominate the tables, which means the recalculation cost is often larger than the configured rules alone suggest.

The single most common mistake is believing that with sharing covers everything. It does not — it enforces record-level sharing only. Object CRUD and field-level security are entirely separate and must be enforced explicitly.

The tools I would expect a developer to use:

1. Sharing keywords: with sharing, without sharing, and inherited sharing, which takes the caller's context and is the right default for a reusable service class.
2. User-mode operations: WITH USER_MODE in SOQL, and AccessLevel.USER_MODE with Database.query and DML, which apply CRUD, FLS, and sharing together.
3. Security.stripInaccessible(): Removes fields the user cannot access from a result set or an inbound payload, without throwing.
4. WITH SECURITY_ENFORCED: Throws when an inaccessible field is referenced — appropriate when you want to fail loudly.
5. Describe checks such as isAccessible() and isUpdateable() for conditional logic.

The second common mistake is Visualforce and Aura controllers: pages on a standard controller enforce sharing, CRUD, and FLS, but a custom controller runs in system context until the developer says otherwise.

I would configure the dashboard with a running user who has the required record access. The components render using that user's access regardless of who views the dashboard, so the executives see aggregate figures without gaining any record access.

The risks are worth stating explicitly, because this is a sanctioned way to move data past the sharing model:

1. The folder access becomes the real security boundary. Whoever can open the dashboard sees the running user's data.
2. Drill-down and export can expose more than intended, so I check what a viewer can actually reach from each component.
3. The running user should be a purpose-built, governed account rather than a real person whose access changes when they move roles — otherwise the dashboard silently changes meaning.

If viewers should each see their own slice, that is a dynamic dashboard running as the logged-in user instead, which is a completely different control and should not be confused with the running-user pattern.

Files have their own sharing surface. A file is linked to a record or a user through a ContentDocumentLink, and two fields on that link do the work:

1. ShareType: Viewer, Collaborator, or Inferred, where Inferred derives the permission from access to the linked record.
2. Visibility: whether the link is exposed to internal users, all users, or only shared users.

The relationship to record sharing is the part that catches people out. Access to a file posted on a record generally follows access to the record, but a file can also be shared directly with users or libraries, which means it can end up more widely accessible than the record it was uploaded against.

In a security review I always check files separately: a confidentiality requirement that is carefully implemented on Opportunity records means very little if the contract PDFs are in a library everyone can read.

Big Objects deliberately omit the sharing model. There are no organization-wide defaults, no sharing rules, no manual shares, and no share table. Access is controlled by object and field permissions only — a user with permission can query the data, and a user without it cannot.

So a per-record confidentiality requirement cannot be met inside the Big Object. The options are:

1. Partition the data into separate Big Objects along the confidentiality boundary and control each with its own permission set.
2. Interpose a controlled access layer — an Apex service or Flow that applies the filtering and that users invoke instead of querying the object directly, with the object permission granted only to that layer's context.
3. Exclude the sensitive attributes from the archive altogether, keeping them in a standard object with a normal retention policy.

I would raise this early, because archiving projects tend to treat the destination as a storage decision when it is also an access-control decision.

I build a persona matrix first: a table of representative users, the records they should and should not see, and the expected access level for each. That artefact is the specification, and everything else verifies against it.

Then:

1. Automated tests using System.runAs to assert access for each persona against seeded records, so regressions get caught by the pipeline rather than by users.
2. UserRecordAccess queries to answer, for a specific user and record, whether they have read, edit, or delete access — the fastest way to settle a dispute.
3. The record's Sharing and Sharing Hierarchy views plus a query on the share table with its RowCause, to see not just whether access exists but which mechanism granted it.
4. A full-copy sandbox for volume-sensitive behaviour, because recalculation duration and skew problems do not appear in a developer org.
5. Business user validation against the matrix before cutover.

What I avoid is testing as an administrator, which proves nothing because administrators bypass sharing, and reviewing configuration in Setup, which confirms intent rather than behaviour.

The direction of travel is a minimal profile carrying only what genuinely has to live there — license, default record types, login hours and IP ranges, page layout assignment — with everything else delivered by permission sets.

1. Permission sets express a single capability, named after what it does rather than who gets it.
2. Permission set groups bundle sets into a job function so that onboarding is one assignment rather than fifteen.
3. Muting permission sets subtract specific permissions from a group's calculated result, which is the sanctioned way to handle "this team, but without Delete on Case" without duplicating the group or editing sets other groups depend on.

The behaviour to be clear about is that object and field permissions combine as a union across the profile and every assigned set. There is no precedence and no conflict resolution. That is why auditing a user's access means enumerating every assignment, and why muting exists at all.

The payoff is fewer profiles. Forty profiles that differ in small ways is a maintenance liability; four profiles and a well-named permission set library is not.

I work from the record outward rather than guessing at configuration.

1. Open the record's Sharing action, which lists who has access and at what level, and the Sharing Hierarchy view, which shows what users derive through the role hierarchy.
2. Query the object's share table for that record and read the RowCause — it names the mechanism: Owner, Manual, Rule, Team, Territory, ImplicitChild, or a custom Apex sharing reason.
3. Query UserRecordAccess for that user and record to confirm the effective access level.
4. Check the user's object permissions for View All or Modify All, and their profile and permission sets for View All Data or Modify All Data, since those bypass sharing entirely and will not appear as share rows.
5. Check whether the access is implicit — a parent Account visible because they can see a child Case is expected behaviour, not a bug.

Only once I know the mechanism do I decide the remedy, because each one has a different fix and the wrong fix usually breaks access for somebody else.

The role hierarchy is the right tool when the access requirement genuinely follows management lines: a manager should see what their subordinates see, transitively, and that relationship is stable.

Public groups with sharing rules are the right tool for cross-cutting access that does not follow the org chart — a compliance function, a shared service desk, a regional overlay team.

The trade-offs:

1. Hierarchy access is automatic and transitive, which is powerful but blunt: you cannot grant a manager access to one subordinate's records and not another's.
2. Every hierarchy level multiplies the share rows maintained and recalculated, so depth has a measurable performance cost.
3. Hierarchy changes are disruptive, triggering recalculation and affecting forecasting and reporting, whereas group membership changes are comparatively contained.
4. Groups are explicit and auditable — a named group with named members is easier to review than an implicit grant three levels up.

The anti-pattern I watch for is roles created purely to grant record access, with no corresponding management relationship. That is a sharing rule wearing a costume, and it should be rewritten as one.

My first assumption is that the requirement has not been normalised, because dozens of distinct criteria on one object is almost always many expressions of a smaller number of underlying categories.

I would work backwards from the audiences. If ninety conditions map onto six or seven distinct populations, then the fix is a derived classification field — a formula or a field maintained by automation — that resolves each record to one of those values, with one sharing rule per value granting to a public group.

That collapses the rule count, keeps the model comprehensible to whoever maintains it next, and stays inside the documented per-object limits on criteria-based rules.

If the logic genuinely cannot be derived from data on the record — for example it depends on a related record's state or an external system — then Apex managed sharing is the legitimate answer. But I would present that as a decision with ongoing cost: recalculation classes, test coverage, and a permanent maintenance obligation.

License type gates which standard objects a user can access at all, before profiles, permission sets, and sharing are consulted. No sharing configuration overcomes a license restriction.

The examples that come up most often:

1. Salesforce Platform covers custom objects plus Accounts, Contacts, Reports, Dashboards, and Documents, but excludes core CRM objects such as Opportunity, Case, Lead, Campaign, and Forecast.
2. Customer Community is high-volume: no roles, no sharing rule participation, so sharing sets and share groups are the only mechanisms.
3. Customer Community Plus and Partner Community are role-based and do participate in the standard sharing constructs.

It should be assessed at the start of the security design, alongside the requirements gathering. The expensive failure mode is designing the sharing model first, then discovering during build that the chosen license cannot participate in it — at which point the choice is a licensing change nobody budgeted for or a redesign nobody planned.

I also verify entitlements against the current Salesforce license comparison rather than from memory, because they change.

View All Data and Modify All Data are system permissions on a profile or permission set. They bypass the sharing model on every object in the org. Modify All Data additionally permits deleting records the user cannot otherwise see, and mass transfer.

View All and Modify All are object permissions, granted per object. They bypass sharing for that object only.

The design guidance follows directly: when a requirement is "this person needs to see all Invoices", the answer is View All on Invoice, not View All Data. Scoping the bypass to the object bounds the damage if the account is compromised or the permission set is over-assigned.

I also treat both as audit items rather than configuration. Any assignment of View All Data or Modify All Data should have a named owner and a stated reason, because they are invisible in the sharing tables — a user with Modify All Data will not appear in any share row, which makes access troubleshooting misleading if you forget to check.

The starting point is that external access is governed separately. Each object has an external organization-wide default alongside the internal one, and it cannot be less restrictive than the internal setting — so external access is a distinct decision, not a side effect of the internal model.

My approach:

1. Set the external OWD to Private on every object partners can reach, then open specific access deliberately.
2. Choose the license by required behaviour: Partner Community or Customer Community Plus if partners need their own hierarchy and sharing rule participation; Customer Community with sharing sets if the population is high-volume and each user only needs their own account's records.
3. Use the account role hierarchy so a partner manager sees records owned by users beneath them within their own partner account, and no further.
4. Use sharing sets rather than sharing rules for high-volume users, and share groups so internal staff can see records those external users own.
5. Review field-level security separately for external profiles, because internal-only fields on shared objects are the most common leak.

Then I test with a real partner user in a full-copy sandbox against the persona matrix, because reasoning about external sharing on paper is unreliable.

The ones I see repeatedly:

1. Treating page layouts as security. A field removed from a layout is still in the API and in reports. Prevented by making field-level security the only accepted answer to "hide this field".
2. Assuming with sharing enforces field-level security. It enforces record sharing only. Prevented by a code review standard requiring user-mode queries or stripInaccessible on anything returned to the client.
3. Starting with a permissive OWD and trying to claw access back with rules that cannot revoke. Prevented by starting Private and justifying every relaxation.
4. Profile sprawl — forty profiles differing in small ways. Prevented by minimal profiles plus a permission set library.
5. Roles created to grant access rather than to model management. Prevented by asking whether a public group and a sharing rule would express it more honestly.
6. Ignoring implicit sharing, then being surprised by parent Account visibility or by an account owner who cannot see child opportunities.
7. Leaving files, reports, and dashboards out of scope, so a carefully restricted object is undermined by an open folder or a running-user dashboard.

The preventive habit behind all of these is the persona matrix: writing down what each population should and should not see, then verifying it with evidence rather than assuming the configuration implies it.