Executive summary

Salesforce security is easiest to reason about as three stacked control planes that all must align: identity/session access, object-and-field permissions, and record-level sharing. Authentication and session controls decide who can get in and under what conditions; profiles, permission sets, and permission set groups decide what capabilities a user has on objects and fields; organization-wide defaults, role hierarchy, sharing rules, teams, manual sharing, territories, and Apex managed sharing decide which specific records are visible or editable. A design is secure only when all three layers are modeled together, because broad CRUD/FLS without restrictive sharing leaks data, while perfect sharing without correct CRUD/FLS still fails secure-by-default design. Salesforce’s own architecture guidance explicitly frames the model this way and recommends locking data down first with org-wide defaults, then opening access selectively.

For modern enterprise orgs, the most resilient pattern is usually: Minimum Access profile (or close equivalent), permission-set-first functional access, private-or-read-only OWD, minimal role hierarchy for managerial roll-up, public-group-based sharing for matrix access, and Apex sharing only when declarative sharing cannot express the rule efficiently. Salesforce recommends permission sets and permission set groups over permission-heavy profiles, and it now also gives architects useful “just-in-time” controls such as muting in permission set groups, assignment expiration, session-based permission set groups, and user access summaries. As of June 2026, Salesforce also canceled the previously announced enforcement of “permissions in profiles” retirement, but their documented best practice remains to keep profiles minimal and move functional access to permission sets.

The deepest architectural mistakes are rarely about missing a single feature; they come from using the wrong primitive for the operating model. Common examples include using the role hierarchy to model overlays or territories, assuming record types are security controls, overusing criteria-based rules when a public-group strategy would scale better, using manual-share row causes in code that must survive ownership transfers, parking too many records under a single owner or parent account, and treating Experience Cloud users as if they all participate in the standard sharing model. Official Salesforce guidance is very direct on these points: role hierarchy should model access roll-up and management, territory hierarchy should model matrix sales access, record types affect process/layout/picklists rather than security, manual shares are removed on owner change, and high-volume external users use sharing sets/share groups instead of role-based sharing.

At scale, security design becomes a performance architecture problem. Sharing recalculation cost is driven by hierarchy changes, ownership changes, public-group maintenance, territory realignments, and explicit share record volume. Salesforce documents concrete guardrails: avoid ownership and parent-child skew above roughly 10,000 records per owner or parent, keep role hierarchies shallow, avoid more than five levels of public-group nesting, test realignments in a full sandbox, and use deferred sharing calculations for major maintenance windows when enabled through support. For very sensitive or regulated orgs, pair the access model with Shield controls: Platform Encryption for at-rest protection, Event Monitoring and Transaction Security for detective and preventive telemetry, and Field Audit Trail for long-lived, compliance-oriented history retention.

flowchart TD
    A[Identity and session] --> B[Object permissions]
    B --> C[Field-level security]
    C --> D[Record-level access]
    D --> E[Effective user visibility]

    A1[SSO / MFA / login hours / IP ranges / connected app policies] --> A
    B1[Profile / permission sets / permission set groups] --> B
    C1[FLS / View All / Modify All nuances] --> C
    D1[OWD] --> D
    D2[Role hierarchy] --> D
    D3[Sharing rules / teams / territories / queues] --> D
    D4[Manual sharing / Apex managed sharing / restriction rules] --> D

The diagram reflects Salesforce’s documented layering of organization/session controls, object- and field-level permissions, and record-level sharing.

Security stack and core concepts

A senior architect should treat the Salesforce model as a sequence of allow gates, not a single switch. Profiles provide baseline user settings such as default record type, login hours, login IP ranges, and some default app behavior; permission sets and permission set groups add functional permissions; FLS decides what fields are readable or editable; sharing decides which records are reachable in the first place. Salesforce explicitly recommends using permission sets and permission set groups rather than profiles for most user permissions, and recommends the Minimum Access profile as a best-practice baseline.

Object-level security is fundamentally CRUD plus exceptional object-wide bypasses. The ordinary object permissions are Create, Read, Edit, and Delete. “View All” and “Modify All” on an object bypass sharing rules and settings for that object and are often preferable to the far broader “View All Data” and “Modify All Data” admin permissions. Field-level security separately determines visibility/editability of fields, which means a user can have read access to a record but still be unable to see sensitive fields. In Apex, “with sharing” does not enforce CRUD/FLS by itself; Salesforce recommends WITH USER_MODE over WITH SECURITY_ENFORCED for query enforcement, and recommends Security.stripInaccessible() when graceful degradation is preferred.

Record-level security starts with organization-wide defaults. OWD establishes the default access for users to records they do not own, and Salesforce’s architecture guide says to set the most restrictive baseline first and then open selectively. External OWD adds separate defaults for authenticated external users and cannot be more permissive than the internal default; Salesforce also notes that external OWD can simplify sharing-rule configuration and improve recalculation performance. Changing OWD is one of the most expensive sharing operations because it triggers sharing recalculation.

Role hierarchy is often misunderstood. It is not supposed to mirror the HR chart perfectly; it should represent levels of data access and reporting roll-up. Users above a subordinate inherit access to records owned by or shared with subordinates, subject to object behavior. For custom objects, you can disable “Grant Access Using Hierarchies,” but for standard objects this control is generally always on. Salesforce recommends keeping role hierarchies shallow and focused; in orgs created in Spring ’21 or later, the documented role limit is up to 5,000 roles, with best-practice guidance to keep internal roles to 25,000 and external roles to 100,000 and the hierarchy to no more than about 10 branch levels.

Public groups are membership containers, not access grants by themselves. They are used as flexible inputs to sharing rules and other access controls. Salesforce allows nested groups, but recommends no more than five nesting levels; its architecture guide also recommends keeping total public groups under 100,000, while its performance guidance says to limit a public group to about 10,000 members for operability. This is why public groups are so valuable for matrix access: they decouple access membership from the role tree without forcing unnecessary hierarchy expansion.

Sharing rules come in two main forms: owner-based and criteria-based. Owner-based rules share records owned by one group with another; criteria-based rules share records whose field values match a condition, independent of owner. They only ever open access; they never make access more restrictive than OWD. Salesforce’s architecture guide documents 300 total sharing rules per object and 50 criteria-based plus guest-user sharing rules per object, with support-based increases for criteria rules available in some cases.

Manual sharing is flexible but fragile. It is appropriate when record-level exceptions are genuinely ad hoc. Salesforce states that manual sharing is removed when record ownership changes, or when the manual share no longer grants additional access beyond OWD. A subtle but important detail is that if your code creates share rows using the out-of-box Manual row cause, those shares behave like manual shares and can be edited/deleted via the Share button and removed on owner transfer.

Apex managed sharing is for requirements that declarative tools cannot express cleanly or efficiently. Salesforce documents that Apex managed sharing is maintained across owner changes, but only for proper Apex-managed shares on custom objects; custom Apex sharing reasons are available only on custom objects, and Salesforce allows up to 10 Apex sharing reasons per custom object. Standard-object share tables differ; for example, CaseShare supports create/edit/delete only when RowCause = Manual. That distinction is one of the most common real-world pitfalls.

Teams, queues, record types, delegated admin, and implicit sharing all matter, but they serve different jobs. Teams are purpose-built, per-record collaboration constructs on Accounts, Opportunities, and Cases. Queues are ownership/distribution mechanisms for supported objects; queue members and users above them in the hierarchy can take ownership of queued records. Record types control business process, page layout, and picklist availability, but do not secure records. Implicit sharing is built-in behavior around Accounts and certain children and cannot be disabled. Delegated administration lets you create groups of users with scoped admin powers and is explicitly separate from public groups used for sharing.

Control surfaces, authentication, monitoring, and governance

For identity and access, Salesforce gives architects a separate set of controls that are related to security but distinct from sharing. Login hours, profile login IP ranges, org trusted IP ranges, session settings, high-assurance session policies, and MFA/step-up govern whether a user session is allowed and how trusted it is. Salesforce documents login IP ranges and session settings as direct access controls; it also documents high-assurance session security as the mechanism for step-up authentication on sensitive operations. In practice, these controls should be treated as your “coarse policy perimeter,” while sharing is your “fine-grained data plane.”

Single sign-on and application integration have also become more nuanced. A connected app enables an external application to integrate with Salesforce using standards such as OAuth, SAML, and OpenID Connect. OAuth access policies can require admin-approved users are pre-authorized, which is a critical least-privilege setting for enterprise integrations. Connected apps also have session policies, and Salesforce supports both SAML and OIDC for service-provider and identity-provider patterns. As of recent releases, Salesforce positions external client apps as the next generation of connected apps, adding stronger inbound-governance patterns and clearer separation between developer-owned configuration and locally governed security policy.

For external and community access, license type matters as much as object configuration. Salesforce’s architecture guide is explicit that high-volume external users do not participate in the standard role-based sharing model, because those license types do not support roles. Instead, access is granted through foreign-key matching via sharing sets and share groups. External OWD is therefore foundational for Experience Cloud designs: make external access private first, then open only what is justified. For guest users, Salesforce warns that guest-user sharing rules expose matching records to anyone without login credentials and should be used only after a deliberate risk review.

The Shield suite sits alongside the core access model and strengthens security in four different ways: Platform Encryption protects data at rest, Event Monitoring provides activity telemetry, Field Audit Trail extends field history retention and depth, and Data Detect assists data discovery/classification. Event Monitoring now spans event log files, event log objects, and real-time event monitoring/transaction security patterns. Salesforce documents event log files as retained for 30 days by default with Shield/Event Monitoring add-on subscriptions, with newer options to retain and download up to one year of event log files. Real-time monitoring and transaction security let you act on events, not just collect them.

Platform Encryption deserves a special architectural note: it is not just a checkbox for compliance. Encryption scheme choice changes application behavior. Salesforce documents that probabilistic encryption is the default, while deterministic encryption is required for some functional scenarios such as filtering or matching on encrypted fields. Deterministic encryption trades some security characteristics for functionality, and not every feature supports every encrypted field behavior. Architects should therefore model encryption alongside UX, search, matching, integration, and reporting requirements—not after them.

Field Audit Trail similarly changes the governance conversation. Standard field history tracking covers far less: the Field Audit Trail implementation guide states FAT supports up to 200 tracked fields per object, stores archived data in FieldHistoryArchive, and by current documentation can retain archived history until deleted. The same guide notes default archive timing of 18 months in production and one month in sandboxes if default retention is used. A widely outdated assumption is that FAT is “just 10 years”; Salesforce release notes now state that the 10-year retention limit is no longer enforced.

Several lesser-known governance tools are worth using much more often in mature orgs. Assignment expiration allows time-bound permission-set or permission-set-group grants; session-based permission set groups support privileged, session-scoped access; permission summaries help compare and review effective access; and delegated administration lets central teams offload user administration without granting broad setup power. These tools are especially useful for privileged-access management, SOX-style control evidence, temporary project access, and distributed admin operating models.

Scenario playbooks and step-by-step solutions

Cross-org sharing between Salesforce orgs

A single Salesforce sharing model does not naturally span multiple orgs; in practice, you choose between federated access, replication, or centralized customer-data patterns. A strong Salesforce-native pattern for operational access is Salesforce Connect Cross-Org, where the subscriber org exposes provider-org data as external objects. Salesforce documents that user access to cross-org external data is determined by settings on both subscriber and provider orgs, and that external objects are read-only by default unless otherwise supported. For multi-org enterprise strategy, Salesforce’s architecture content also points to centralized Data 360/Data Cloud patterns where a central data org supports multiple Salesforce orgs.

Recommended sequence: Create SSO between orgs so identity is consistent; configure a connected app or Salesforce authentication provider for trust; define the cross-org external data source with per-user auth where appropriate; expose only the necessary external objects; apply object/FLS and restriction rules in the subscriber org; and separately verify provider-org sharing to ensure the remote user is entitled to the source record. If writeback or offline analytics is needed, shift from federation to integration/replication and enforce security locally in the target org.

Multi-division data visibility in a single org

The common anti-pattern is encoding business-unit segmentation entirely in the role hierarchy. Salesforce’s guidance is to use OWD as the restrictive baseline, model the role tree for managerial reporting and roll-up, and use public groups plus owner-based or criteria-based sharing rules for overlay or cross-division access. If a subset of records remains sensitive even after broader sharing, add restriction rules for a “need-to-know” overlay.

Recommended sequence: Set key objects to Private or Public Read Only as needed; design separate role-tree branches for each division; create public groups for cross-divisional consumers such as finance, legal, or PMO; use owner-based sharing rules where access follows ownership branches, and criteria-based rules where access follows attributes such as region, product line, or legal entity; reserve restriction rules for the sensitive subset. Avoid using record types as a substitute for sensitivity labels because record types do not enforce security.

Community and portal access

Experience Cloud access design starts with license semantics. High-volume users do not use the standard role-based sharing model, so sharing sets and share groups are the primary tools. External OWD should usually be Private, and guest access should be opened with extreme caution. Salesforce explicitly recommends using sharing sets and share groups when possible for external users tied to account/contact relationships.

Recommended sequence: For partner users with roles, use external OWD plus role/public-group sharing when role-driven collaboration is acceptable. For customer/high-volume users, create sharing sets based on Account or Contact lookups, and use share groups when records owned by high-volume users must be visible to internal or authenticated external users. For guest users, assume OWD is effectively private and use guest-user rules only for narrowly scoped, non-sensitive records after review. Test every persona with a clean browser session because admin visibility often hides Experience Cloud misconfigurations during troubleshooting.

Large data volumes and sharing recalculation during realignment

At LDV scale, sharing maintenance is itself a deployment event. Salesforce documents that defer sharing calculations can suspend sharing-rule and group-membership calculations during large updates, but it must be planned, tested, and resumed promptly. Ownership skew and account/parent-child skew at around 10,000 records become material performance risks. If you model access inefficiently and generate huge volumes of explicit grants, Salesforce warns that major realignments can create long-running recalculation.

timeline
    title LDV sharing-change maintenance window
    section Preparation
      Sandbox rehearse : volume test realignment
      Enable defer sharing : if support-approved and appropriate
    section Change window
      Suspend group membership calc : start maintenance
      Suspend sharing rule calc : start maintenance
      Bulk role/group/territory/ownership updates : execute
    section Recovery
      Resume calculations : immediately after changes
      Run full recalculation : low-traffic window
      Validate access and lock-contention metrics : post-check

This sequence closely follows Salesforce’s documented guidance on deferring calculations, testing in full sandboxes, and resuming calculations promptly.

Recommended sequence: Profile the current share-table volume first; rehearse in a full sandbox; reduce avoidable skew by rebalancing record ownership and hot parent accounts; enable deferred sharing if the org is eligible and the change warrants it; freeze admin changes during the window; make hierarchy/group/rule changes in batches; resume calculations immediately after the change; then run the full recalculation during low activity and validate with sample users, lock monitoring, and Event Monitoring where available.

Territory management versus role hierarchy

Salesforce’s own guidance is unusually crisp here: use the role hierarchy for management relationships, approvals, and reporting roll-up, and use the territory hierarchy to extend access based on account/territory assignment. Salesforce specifically recommends not making the role and territory hierarchies identical, because that causes unnecessary sharing activity. Territory models also support planning-state changes before activation, which is invaluable for realignment exercises.

Recommended sequence: Keep the role tree relatively flat and aligned to management reporting; create territory types and a territory model in planning state; assign accounts, users, and leads through rules or manual assignments; activate only after validation; and resist the temptation to mirror the territory hierarchy in roles. If overlays exist in stable territory-shaped structures, prefer territories over per-record teams. If the access need is truly one-off, use teams.

Apex sharing with bulkification and governor awareness

Apex sharing is justified when no declarative sharing tool matches the rule, when an external system is the access source of truth, or when native sharing components perform poorly at scale. For the business-object read/write path, remember that Apex runs in system mode by default unless you opt into user mode or security enforcement. For the sharing path, use custom Apex sharing reasons on custom objects if shares must survive ownership changes, and always bulkify: aggregate target principals per parent record, build share rows in memory, and perform a single partial-success DML.

public with sharing class InvoiceShareService {
    public static void shareInvoices(Map<Id, Set<Id>> invoiceToUserIds) {
        List<Invoice__Share> shares = new List<Invoice__Share>();

        for (Id invoiceId : invoiceToUserIds.keySet()) {
            for (Id userOrGroupId : invoiceToUserIds.get(invoiceId)) {
                Invoice__Share s = new Invoice__Share();
                s.ParentId = invoiceId;
                s.UserOrGroupId = userOrGroupId;
                s.AccessLevel = 'Edit';
                s.RowCause = Schema.Invoice__Share.RowCause.Finance_Team__c;
                shares.add(s);
            }
        }

        if (!shares.isEmpty()) {
            Database.SaveResult[] results = Database.insert(shares, false);
            // log failures, do not throw away successful shares
        }
    }
}

This pattern is appropriate for custom objects that use a custom Apex sharing reason. Salesforce documents custom sharing reasons for custom objects, recommends bulk sharing via Apex, and notes that Apex managed sharing survives owner changes, unlike manual-row-cause shares.

Recommended sequence: First decide whether the access rule is really record-level and not better expressed through ownership or public-group sharing. Then implement selectors/services with with sharing where appropriate, enforce CRUD/FLS via WITH USER_MODE or Security.stripInaccessible(), bulk-recompute principal assignments, upsert/delete share rows in batch form, add a recalculation class if your share reasons require rebuild support, and write negative tests for owner transfer, hierarchy changes, and revoked source entitlements.

Sharing with external users from Apex or declarative rules

Salesforce explicitly notes a nuance that trips up many teams: to secure external users’ access, Apex code often needs to share to the Role and Internal Subordinates group rather than older model assumptions. External OWD and external-user role structure also interact with manual/Apex shares, especially for partner users. For high-volume external users, Apex sharing is usually the wrong first choice if a sharing set can express the relationship.

Recommended sequence: Classify the external license first. If partner roles exist and collaboration is role-driven, use sharing rules or Apex shares to the correct role-group construct. If the user is high-volume, prefer sharing sets/share groups. Keep the external baseline private. Test from a true external persona, not “Login As” alone, when debugging list-views, related lists, and site visibility.

Record ownership transfers and cascading sharing

Ownership transfer is not just a field update; it triggers security side effects. Salesforce documents that manual shares created by the original owner are deleted on ownership transfer, sharing rules are reevaluated, and for Cases/Contacts/Opportunities the new owner often must already have at least Read access to the associated parent Account unless the transfering user itself has parent-account sharing rights. This is why ownership-transfer projects can create sudden “inexplicable” access loss.

Recommended sequence: Before bulk transfer, inventory manual-share dependencies and replace durable needs with declarative rules, teams, or Apex-managed custom-object sharing. Check parent-account access prerequisites. Use mass transfer only after rehearsal with a sample cohort. If standard-object manual shares are being used programmatically, redesign before the transfer because those shares are not durable. For account transfers, decide deliberately whether related closed or open child records should transfer too, because ownership-change options vary by method.

Performance, limits, hidden pitfalls, and lesser-known features

Architecturally, the key performance question is not “how many records exist?” but “how much sharing work does each change generate?” Salesforce’s under-the-hood paper explains that when OWD is restrictive, the platform computes and stores access grants—explicit, group-membership, inherited, and implicit—to avoid expensive runtime evaluation. That means your design quality is reflected in how many share-table rows and group-maintenance operations Salesforce must create and recalculate. If you create huge explicit-share footprints through over-granular criteria rules, bloated hierarchies, or constant territory realignment, the system pays for that every time access-changing events occur.

Several official thresholds and limits are worth treating as design constraints rather than trivia. Salesforce recommends avoiding parent-child and ownership skew beyond roughly 10,000 records, keeping role hierarchies shallow, limiting public-group nesting to five levels, and being cautious when crossing the millions-of-records threshold on access-heavy objects—especially Accounts with teams or ETM. Sharing-rule limits also matter: 300 total sharing rules per object and 50 criteria-based/guest rules per object by default are enough for many orgs, but not for poorly normalized access models. Restriction rules are intentionally limited as well, which means they are scalpels, not hammers.

The most damaging hidden pitfalls are the ones architects “know,” but incorrectly. Record types do not secure data. Account hierarchy does not confer child-account access. Manual shares are not durable across owner transfers. High-volume external users do not follow the normal sharing model. With sharing is not enough for CRUD/FLS. View All/Modify All on an object bypass sharing and often explain “mystery visibility.” Each of those points is either directly documented by Salesforce or explicitly called out in its architecture guidance, yet they still account for many production surprises.

Lesser-known features and tricks deserve a place in advanced designs because they reduce both risk and operational friction. Session-based permission set groups are excellent for privileged tasks such as data fix, deployment review, or support escalation. Assignment expiration prevents “temporary” elevated access from becoming permanent. Access summaries make entitlement regression testing easier during migrations. Restriction rules are powerful when you need to subtract visibility after broad sharing, especially on Tasks, Events, Contracts, and eligible custom/external objects. External client apps are the strategic successor for some inbound-integration governance patterns.

A final advanced nuance: if you encrypt or share late in the lifecycle, you often discover that non-security requirements were quietly depending on broader access or plaintext behavior. Encryption may affect filter/match behavior depending on deterministic versus probabilistic schemes. Restriction rules are not universally applied in without sharing Apex. And custom-object Apex-managed sharing can be rebuilt with proper recalculation logic, but standard-object “manual” share row semantics do not give you the same durability model. These are not edge conditions; they are architecture decisions with long tails.

Hardening checklist, migration strategy, and change management

A robust security-hardening program in Salesforce should be designed like an engineering control system, not like a one-time audit. Start with least-privilege entitlement design: minimal profiles, permission-set-first grants, systematic removal of object-level “View All” and “Modify All” where not justified, and a review of every powerful system permission. Then harden identity and session posture: enforce MFA, require high-assurance for sensitive setup operations, use profile login IP ranges and trusted-network controls where appropriate, and review connected-app OAuth policies so that external applications are admin-approved and narrowly scoped. Finally, harden the data plane: private or read-only OWD by default, principled role-tree design, public-group normalization, and explicit review of external OWD, guest access, and manual-share dependencies.

A practical hardening checklist for senior teams is this:

• Use a minimal base profile and move functional access to permission sets and permission set groups.
• Inventory object-level View All and Modify All; justify or remove them.
• Review every integration for OAuth scopes, admin-approved users, session policy, and potential migration to external client apps.
• Keep external OWD private unless a documented use case requires otherwise; explicitly review guest-user exposure.
• Replace durable manual-sharing dependencies with declarative rules, teams, or custom-object Apex-managed sharing before ownership migrations.
• Use Shield where justified for encryption, telemetry, and audit durability.
• Turn temporary privileged access into session-based or expiring permission assignments.
• Add access-regression tests for persona/object/field/record expectations. Salesforce access summaries materially help here.
• For LDV orgs, maintain a “sharing-change runbook” including sandbox rehearsal and deferred-calculation procedures.

For migrations, the safest strategy is persona-first decomposition. Start by extracting current profile permissions into human-meaningful tasks and personas, then build reusable permission sets from those tasks and compose them into permission set groups. Keep the profile minimal for login settings, default record type, and base usability settings. Because Salesforce canceled the hard retirement enforcement for permissions in profiles, you have operational flexibility, but not an excuse to preserve profile sprawl; the best-practice direction is still clearly toward permission sets and groups.

When the migration also changes sharing, treat it as a data-plane refactor. Build a matrix of persona × object × field × record access; use user access summaries to compare expected versus actual; migrate in slices by business function rather than by metadata type; and instrument the cutover with login history, event monitoring, support runbooks, and rollback criteria. For high-volume changes to roles, groups, territories, or OWD, rehearse in a full sandbox and schedule a maintenance window with sharing recalculation explicitly accounted for.

flowchart LR
    A[Inventory current profiles and shares] --> B[Define personas and tasks]
    B --> C[Build permission sets]
    C --> D[Compose permission set groups]
    D --> E[Model target sharing]
    E --> F[Sandbox regression tests]
    F --> G[Phased production rollout]
    G --> H[Telemetry and access verification]
    H --> I[Retire legacy profiles and rules]

That migration sequence aligns with Salesforce’s current profile-to-permission-set guidance and its recommendation to validate large sharing changes in sandbox first.

Advanced interview and scenario Q&A

The following questions are optimized for senior architects and lead engineers. Each answer is brief but intentionally analytical.

Advanced interview questions

1. What is the precise order of thinking for Salesforce data access?

Start with identity/session access, then object permissions, then field-level security, then record-level access. A user must pass all layers; CRUD/FLS alone is not enough, and record visibility alone is not enough.

1. Why does Salesforce recommend restrictive OWD first?

Because OWD is the baseline for all non-owners; starting restrictive gives you predictable additive sharing later. Salesforce’s architecture guidance explicitly recommends locking data down first and opening it selectively.

1. Why are permission sets preferred over heavily customized profiles?

They are reusable, additive, and composable, which reduces profile sprawl and makes least-privilege maintenance easier across personas. Salesforce documentation and admin guidance explicitly recommend this model.

1. What is the real purpose of a profile in a modern design?

Primarily baseline user settings such as login hours, IP ranges, default record type, and a minimal permission floor. Functional entitlements should usually move to permission sets and groups.

1. What is the difference between CRUD/FLS and sharing?

CRUD/FLS governs what operations and fields are permitted on an object; sharing governs which records are in scope. They are orthogonal and both must be enforced.

1. What is the danger of with sharing being treated as “fully secure Apex”?

with sharing enforces record-level sharing but not object and field permissions by itself. Salesforce recommends user-mode queries/operations or Security.stripInaccessible() for CRUD/FLS enforcement.

1. Why is WITH USER_MODE generally preferred over WITH SECURITY_ENFORCED now?

Salesforce explicitly recommends WITH USER_MODE because it supports broader security enforcement behavior. WITH SECURITY_ENFORCED still exists, but user mode is the preferred modern pattern.

1. When should you disable Grant Access Using Hierarchies?

Only for eligible custom objects, and only when managers should not automatically inherit subordinate access. It is not available as a general control for standard objects.

1. Why is role hierarchy a bad fit for overlays?

Because role hierarchy is intended for management/reporting roll-up; overlays create cross-branch or matrix access that is better handled with public groups, sharing rules, teams, or territories. Salesforce explicitly warns architects about overlays in the hierarchy.

1. When is an owner-based sharing rule better than a criteria-based one?

When access follows ownership structure rather than record attributes. It is especially effective for cross-branch managerial or department access tied to owner membership.

1. When is a criteria-based rule the wrong answer even if it works logically?

When it causes rule explosion, poor maintainability, or excessive recalculation cost compared with public-group normalization or other structural approaches. Salesforce’s rule limits and recalculation guidance make this a scale concern, not just a metadata concern.

1. What is a public group, and what access does membership alone grant?

It is a membership container for users, roles, territories, and other groups. Membership alone grants no data access until another sharing mechanism uses that group.

1. Why are nested public groups both useful and dangerous?

They decouple matrix access from the role tree, but excessive nesting increases group-maintenance cost and troubleshooting complexity. Salesforce recommends no more than five levels.

1. What is implicit sharing, and why do architects need to know it?

It is built-in, non-configurable account-centric access behavior between certain parent and child records. It explains visibility that does not come from your explicit share model and cannot be disabled.

1. Does an account hierarchy grant access down the account tree?

No. Salesforce explicitly notes that parent-child account hierarchy does not itself drive data access the way role or territory hierarchies do.

1. Are record types a security boundary?

No. They control process, page layout, and picklist availability, not record security. Treating them as a sensitivity boundary is a design mistake.

1. How do queues differ from sharing rules?

Queues are ownership/distribution mechanisms for unassigned work on supported objects; sharing rules are additive access grants. A queue is not a generic substitute for matrix visibility.

1. Why is manual sharing dangerous in long-lived business processes?

Because it is removed on owner change and when it no longer adds access beyond OWD. It is appropriate for true exceptions, not durable business entitlements.

1. What is the key semantic difference between manual sharing via Apex and Apex managed sharing?

Shares created with the Manual row cause behave like manual shares and can be removed on owner transfer; true Apex managed sharing on custom objects with custom reasons is durable across ownership changes.

1. Can you create custom Apex sharing reasons on standard objects?

No; custom Apex sharing reasons are for custom objects. Standard-object share tables have different semantics and are often limited to Manual programmatic share creation patterns.

1. What is the architecturally correct use of Enterprise Territory Management?

Use it to model account/territory-based matrix access and planning/realignment, while keeping role hierarchy focused on management/reporting. Salesforce explicitly recommends not mirroring both hierarchies.

1. Why can high-volume external users not be treated like internal users for sharing?

Because those licenses do not support roles and therefore do not use the standard role-based sharing model. Access is instead driven through sharing sets and share groups.

1. What is the safest baseline for external OWD?

Private, then open selectively. Salesforce’s Experience Cloud guidance strongly recommends this pattern.

1. What is the risk profile of guest-user sharing rules?

They expose every matching record to unauthenticated users without login credentials. Salesforce explicitly warns architects to assess sensitivity and implications before creating them.

1. What is data skew, and why does it matter to security architecture?

It is a concentration problem—too many records under one owner, parent, or lookup target—which can significantly degrade sharing recalculation and locking behavior. Security design choices often create or worsen it.

1. When should deferred sharing calculations be considered?

During large-scale hierarchy, group, or sharing-rule changes where automatic recalculation would be too costly during active hours. Salesforce recommends planning, sandbox testing, and quick resumption afterward.

1. How should architects think about Shield Platform Encryption?

As a functional-security tradeoff, not just a compliance control. Encryption scheme choice affects matching, filtering, and some downstream features, so it must be designed with application behavior in mind.

1. What does Event Monitoring add beyond Login History and Setup Audit Trail?

Granular user-activity telemetry, event log files/objects, and real-time events that can power transaction security policies and forensics. It is far broader than admin audit trails alone.

1. Why is Field Audit Trail materially different from standard field history tracking?

Because it supports far more tracked fields, archival storage, and long-lived retention policies suitable for compliance. Current Salesforce guidance documents up to 200 fields per object and archived retention until deleted.

1. What is the strategic significance of external client apps?

They are the next-generation framework for inbound integration governance, giving admins and architects stronger control separation and policy layering than legacy connected-app-only models.

Tricky scenario-based questions

1. A user has no sharing rule to an Opportunity, but can still see the Account. Why?

Parent implicit sharing can expose the Account when the user has access to a child Opportunity, Case, Contact, or Order. Troubleshooting must therefore consider implicit access, not just explicit share records.

1. A manager should not see subordinate records on a custom HR object. What is the cleanest fix?

Set OWD to Private and disable Grant Access Using Hierarchies on that custom object, then open access only via explicit sharing where needed. This is exactly the kind of use case Salesforce documents for custom-object hierarchy control.

1. A team uses record types to separate “Sensitive” and “Non-Sensitive” Cases. Why is this insufficient?

Because record types do not secure records. Use OWD/sharing plus, if needed, restriction rules or separate object patterns for true need-to-know control.

1. A bulk ownership transfer caused users to lose access despite no profile changes. What likely happened?

Manual shares tied to the old owner were removed, and the new ownership pattern did not recreate equivalent access through durable sharing mechanisms. Sharing rules were reevaluated, but manual-share exceptions were not preserved.

1. A custom object uses Apex-created share rows with RowCause = Manual, and the team expects them to survive owner changes. What is wrong?

Manual-row-cause shares behave like manual shares and are removed on owner transfer. On custom objects, use proper Apex-managed sharing with a custom sharing reason when durability is required.

1. An org wants overlay sales reps to see records across regions. Should roles be expanded?

Usually no. Use public groups, sharing rules, teams, or ETM depending on whether the access is per-record, per-owner-branch, or territory-shaped. Expanding roles for overlays often corrupts the hierarchy’s intended purpose.

1. A partner user can see their Account but not a related custom object row even though the row is “controlled by parent.” Why might that happen?

Controlled-by-parent depends on the actual relationship semantics and the user’s access to the controlling parent. In Experience Cloud, you must also validate license type, external OWD, and whether the object participates in the expected sharing path.

1. A secure Apex service uses with sharing but still leaks hidden fields in responses. How?

Because record-level sharing was enforced, but FLS/CRUD was not. Use user mode or Security.stripInaccessible() before returning data.

1. A customer community solution uses hundreds of criteria-based sharing rules per geography/account type. Why is this a warning sign?

High-volume external access is usually better modeled through sharing sets/share groups and external OWD. Excessive criteria rules consume scarce limits and increase recalculation cost.

1. An architect proposes cloning the role hierarchy into ETM for “consistency.” Why should you push back?

Because Salesforce explicitly recommends not making the role and territory hierarchies identical; it creates unnecessary sharing activity and blurs the distinct purposes of management roll-up versus territory access modeling.

Reference map

The most authoritative primary sources for this topic are Salesforce’s Platform Sharing Architecture guide, the Record-Level Access: Under the Hood paper, the Apex security and sharing developer docs, the Sales Territories Implementation Guide, the Shield / Event Monitoring / Platform Encryption / Field Audit Trail docs, and the Experience Cloud external sharing help and Trailhead content. Those sources should be treated as the baseline; use authoritative Salesforce blogs and admin content to track newer patterns such as external client apps, modern event-monitoring architecture, and profile-to-permission-set migration design.