• Cert++
  • Practice
  • Certle
  • Review
  • Tracks
  • Checklist
  • Guides
  • Upgrade
Cert++
  1. Home
  3. Platform Sharing and Visibility Architect

Platform Sharing and Visibility Architect

Checklist progress

0/151Learned

Platform Sharing and Visibility Architect

Study Checklist

  • Platform Administrator
  • Platform App Builder
  • Platform Foundations
  • Platform Developer
  • Platform Administrator II
  • Agentforce Sales Consultant
  • Agentforce Service Consultant
  • Platform Data Architect
  • Platform Development Lifecycle and Deployment Architect
  • Platform Identity and Access Management Architect
  • Platform Integration Architect
  • Platform Sharing and Visibility Architect
  • Heroku Architect
  • B2C Solution Architect
  • Experience Cloud Consultant
  • Agentforce Field Service and Operations Consultant
  • Agentforce Nonprofit Consultant
  • Data 360 Consultant
  • Omnistudio Consultant
  • CRM Analytics and Einstein Discovery Consultant
  • Platform User Experience Designer
  • Platform Strategy Designer
  • B2C Commerce Developer
  • JavaScript Developer
  • Omnistudio Developer
  • Platform Developer II
  • Marketing Cloud Engagement Administrator
  • Marketing Cloud Engagement Specialist
  • Marketing Cloud Engagement Consultant
  • Agentforce Sales Foundations
  • Business Analyst
  • Marketing Cloud Engagement Developer
  • Marketing Cloud Engagement Foundations
  • Agentforce Specialist
  • Agentforce Life Sciences Consultant
  • B2B Commerce Administrator AP
  • B2B Commerce Developer AP
  • Agentforce Consumer Goods AP
  • Agentforce Financial Services AP
  • Agentforce Health AP
  • Agentforce Manufacturing AP
  • MuleSoft Integration Foundations
  • MuleSoft Developer
  • MuleSoft Developer II
  • MuleSoft Platform Integration Architect
  • MuleSoft Platform Architect
  • Tableau Desktop Foundations
  • Tableau Data Analyst
  • Tableau Consultant
  • Tableau Server Administrator
  • Tableau Architect

Checklist progress

0/151Learned

Given a scenario, recommend the right level of object permissions needed to provide the appropriate access to a set of users.

0/11

  • How profiles and permission sets work together to grant object permissions.
  • Why a user's effective object access is always the union (most permissive) of all assigned profiles and permission sets.
  • How permission set groups aggregate multiple permission sets.
  • Difference between 'View All' and 'Read' object permissions and when each is the correct choice for a user who should see all records regardless of OWD.
  • 'View All Data' and 'Modify All Data' system permissions: what they override and which objects they apply to.
  • Why assigning 'View All Data' or 'Modify All Data' is architecturally equivalent to bypassing all record-level sharing.
  • How 'Modify All' object permission interacts with record-level sharing rules and OWD settings when a user must manage all records regardless of ownership.
  • Which object permission combination (Read, Create, Edit, Delete, View All, Modify All) is appropriate given a business role that needs to update existing records but never delete them?
  • Which permission set or profile configuration allows a user to create and edit Contacts but not delete them, while still viewing all related Accounts?
  • Selecting the minimum necessary object permissions for a read-only integration user that must access all Opportunity records without opening up record sharing broadly.
  • How muting permission sets within a permission set group can restrict specific permissions that member permission sets would otherwise grant.

Given a scenario, recommend the correct level of field permissions needed to provide the appropriate access to a set of users.

0/5

  • How field-level security (FLS) interacts with page layouts to control field visibility and the authoritative control mechanism when both are configured differently.
  • Impact of setting a field to 'Read-Only' in FLS versus removing it from the page layout on API access and programmatic SOQL queries.
  • Which approach grants field-level read access to a subset of users without modifying the profile shared by all users in that role?
  • How to enforce that a sensitive custom field on Case is visible only to support managers using permission sets while keeping the field accessible to automation.
  • Given a scenario where a user can see a field on the page layout but not through the API, which FLS configuration is the cause and how to resolve it.

Given a scenario, recommend the appropriate mechanism to hide data at the user interface level.

0/4

How record types in conjunction with profiles control which picklist values and page layouts a user sees.

Learn this concept
Unseen

When record types alone are insufficient for access control.

Learn this concept
Unseen

Choosing between page layout removal, FLS hidden, and record type restrictions to hide a set of fields from a specific user population in the UI.

Learn this concept
Unseen

Limitations of hiding data only at the UI layer when the data is still accessible via SOQL, API, or reports — and the recommended architectural fix.

Learn this concept
Unseen

Given a scenario, determine the appropriate access controls to protect sensitive data

0/6

  • How Salesforce Shield Platform Encryption differs from Classic Encryption.
  • Which encryption (Shield vs Classic) should be used to satisfy HIPAA requirements for a health data field.
  • Which combination of Platform Encryption, FLS, and object permissions is appropriate to protect PII fields from being viewed by support agents while allowing billing users access?
  • Given PCI compliance requirements, which access control mechanisms must be layered to prevent unauthorized users from viewing cardholder data fields in Salesforce?
  • Audit trail and event monitoring capabilities in Salesforce used to detect and report on unauthorized access attempts to sensitive data.
  • When should an architect recommend data masking via a custom solution versus native Salesforce field encryption for protecting PII in a multi-cloud integration?

Given a scenario, recommend the appropriate programmatic solution to ensure security settings are enforced.

0/8

  • Difference between 'with sharing', 'without sharing', and 'inherited sharing' in Apex and when each keyword is correct for a class that processes sensitive Contact records.
  • How SOQL in an Apex trigger enforces (or bypasses) record-level sharing depending on the class-level sharing declaration.
  • The correct approach when an Apex trigger must respect row visibility for non-admin users.
  • How WITH SECURITY_ENFORCED or stripInaccessible() in Apex enforces FLS and object-level permissions for programmatically queried data.
  • How the Security.stripInaccessible() method behaves when applied before DML operations to prevent unauthorized field writes.
  • A developer's Apex class runs in system mode and bypasses FLS. Which code-level changes enforce field security without breaking existing functionality?
  • How Visualforce and Lightning Web Components differ in enforcing FLS automatically, and what developers must do to avoid FLS bypass in each.
  • When a batch Apex job must access all records regardless of sharing but must still respect FLS, which class-level sharing keyword and SOQL approach is appropriate?
  • How OWD settings for a given object establish the baseline record access and why setting OWD to 'Public Read/Write' makes all sharing rules redundant.
  • When is 'Private' OWD appropriate versus 'Public Read Only', given a business requirement where managers should see all subordinate records but reps should only see their own?
  • The 'Controlled by Parent' OWD setting for a custom object and how it governs record access relative to the Lookup or Master-Detail parent relationship.
  • How OWD for a child object relates to OWD for the parent in a Master-Detail relationship and what access a user gains to child records through the parent.
  • How external OWD settings differ from internal OWD settings and why they can be set independently for each object.
  • When setting a lower external OWD is architecturally required.
  • A company has internal OWD of Public Read Only for Accounts but needs portal users to see only their own account data. Which external OWD setting achieves this without additional sharing rules?
  • Which combination of OWD settings for Accounts and Contacts ensures that portal users can only see Contacts directly associated with their Account?
  • Given a regulated healthcare org, which OWD baseline for Patient records minimizes exposure while allowing controlled sharing via exception rules?
  • How the role hierarchy grants implicit record access upward and the conditions under which a manager does NOT automatically inherit access to a subordinate's record.
  • How 'Grant Access Using Hierarchies' checkbox for an object affects whether role hierarchy-based access applies.
  • A sales manager needs to see all Opportunities owned by their direct and indirect reports. Which role hierarchy configuration achieves this without sharing rules?
  • How position in the role hierarchy determines which sharing rule targets (Roles, Roles and Subordinates) grant access to a given user when a sharing rule is evaluated.
  • When an architect should choose a flat role hierarchy over a deep role hierarchy.
  • Scalability implications of flat versus deep role hierarchies.
  • An org has a matrix structure where users report to multiple managers. Which Salesforce mechanism compensates for the single-parent role hierarchy limitation?
  • When turning off 'Grant Access Using Hierarchies' for an object is appropriate.
  • Difference between criteria-based sharing rules and ownership-based sharing rules, and when each is the correct choice for a specific access pattern.
  • Sharing rules can only open access beyond OWD, never restrict it. What are the implications when a sharing rule grants broader access than intended?
  • When sharing rules reference public groups versus roles or role-and-subordinates, and which target provides better long-term maintainability for a dynamic org.
  • A business unit requires that all Cases with a specific record type be visible to a separate support tier group. Which sharing rule type and configuration achieves this?
  • How queues can be used as a sharing rule target to grant record access to all members of a queue.
  • Difference between queue membership-based access and role-based sharing rule access.
  • A service team uses a queue to manage unassigned Cases. Which sharing configuration ensures that all queue members can edit any Case in the queue while non-members cannot see the records?
  • How criteria-based sharing rules recalculate when a record's field value changes, and which scenarios may result in stale sharing or delayed access.
  • Maximum number of sharing rules per object (300 owner-based + 300 criteria-based).
  • Implications when the sharing rule limit is approached in a large org with complex access patterns.
  • Difference between public groups, personal groups, and role-based groups.
  • Which group type is correct for sharing records with a cross-functional team that spans multiple roles.
  • How queues differ from public groups in terms of record ownership, member types, and the objects they can be associated with.
  • When a queue is the correct mechanism over a public group.
  • How public groups interact with the role hierarchy when a group includes 'Roles and Subordinates' as a member and what access that grants at scale.
  • A company wants to grant a temporary cross-regional team access to a set of Account records. Which group type and sharing mechanism is most maintainable and scalable?
  • How nesting public groups affects sharing rule evaluation and performance, and when deeply nested groups become an architectural risk.
  • How Account Teams and Opportunity Teams grant record-level access.
  • When Account Teams and Opportunity Teams are the correct mechanism versus sharing rules for dynamic, owner-controlled sharing.
  • Limitations of Account Teams and Opportunity Teams — what they cannot do (e.g., grant access to related objects) and when a different mechanism is required.
  • How Case Teams differ from Account Teams in terms of configuration and access inheritance.
  • When Case Teams are the appropriate solution versus Account Teams.
  • How default Account Team and Opportunity Team templates work and which sharing access levels they support.
  • When a sales rep adds a colleague to an Opportunity Team with 'Read Only' access but the colleague still needs to edit the Opportunity, which additional configuration is required?
  • Behavior when a team member is removed from an Account Team or Opportunity Team.
  • How a Master-Detail relationship automatically shares child record access with users who have parent record access, and how this differs from a Lookup relationship.
  • When a Lookup relationship is used instead of Master-Detail, what additional sharing configuration is required to ensure child records are visible to users who can see the parent?
  • An architect must ensure that child Service Appointment records are only visible to users who can see the parent Work Order. Which relationship type enforces this automatically?
  • How Many-to-Many relationships via junction objects affect record visibility.
  • Which OWD and relationship type combination ensures both parent owners can access a junction record in a Many-to-Many relationship.
  • How implicit sharing for portal users on Accounts and Contacts works: a portal user with access to an Account automatically gains access to Contacts associated with that Account through the implicit sharing mechanism.
  • How Apex managed sharing works using the Share object (e.g., AccountShare, OpportunityShare) and which fields are required when inserting a share record programmatically.
  • What a custom Apex sharing reason (row cause) is and how to create one.
  • Why a custom row cause is required to prevent Apex-managed share records from being deleted when the record owner changes.
  • How Apex managed sharing records are affected when the sharing reason is not specified, and the implications for recalculation when the record owner changes.
  • How 'without sharing' classes interact with Apex sharing records and whether a class running in system mode can read and insert Share object records.
  • When programmatic sharing is the right choice over criteria-based sharing rules, given a dynamic sharing requirement that depends on complex related-object field values.
  • A trigger needs to share a newly created custom object record with a specific set of users based on business logic. What are the architectural steps using Apex managed sharing?
  • When a custom object's sharing table (e.g., MyObject__Share) is queried to audit who has access and why, which fields indicate the sharing source and what the RowCause values mean.
  • How Experience Cloud (Community) user access to records is governed by OWD for external users and the difference between internal and external OWD settings.
  • How Customer Community versus Customer Community Plus licenses differ in role hierarchy support and the sharing mechanisms available to each.
  • When Customer Community Plus is architecturally required versus Customer Community.
  • Which portal/Experience Cloud license types support object-level sharing rules.
  • How account hierarchy-based implicit sharing works for portal users: a portal user gains access to records owned by users at their account and parent accounts in the hierarchy.
  • Given a partner portal scenario, which sharing mechanism grants portal users access to Account records they do not own without exposing internal records broadly?
  • How super user access for partner portal users works.
  • When super user access should be used to grant broader record access within an account hierarchy.
  • A customer community user should see only their own Cases and Cases shared explicitly by a support agent. Which combination of OWD and sharing mechanism achieves this?
  • Guest user record access limitations (no role, no manual sharing).
  • Restrictions on the types of sharing rules that apply to guest users.
  • How to compensate for guest user limitations using public groups and criteria-based sharing rules for unauthenticated users.
  • How manual sharing allows record owners and administrators to grant one-time access and the limitations of manual shares when ownership changes.
  • When is manual sharing the appropriate override mechanism versus a permanent sharing rule, given a one-time cross-team collaboration requirement?
  • How 'View All' and 'Modify All' object permissions override all record-level sharing mechanisms, including OWD, sharing rules, and manual shares.
  • System Administrator profile access: why admins can see all records regardless of OWD and sharing rules, and how to model a scenario where even admins should be restricted.
  • How to use the 'Why can I see this record?' (Sharing Hierarchy / Record Access) tool in Salesforce to diagnose unexpected record visibility.
  • How the Sharing Debugger (Setup > Sharing Settings > Debug) works and what information it surfaces about a user's access to a specific record.
  • Given a scenario where a user unexpectedly has access to a record, which combination of sharing sources (OWD, hierarchy, sharing rules, manual share, Apex share) could explain it?
  • When using High Volume Customer Portal (HVCP) users, which standard sharing mechanisms are unavailable and what must replace them?
  • How Reports and Dashboards folder sharing works and what access level is required to view, edit, or manage folders.
  • How the 'running user' setting on a dashboard controls which records appear in charts and metrics.
  • An executive team needs a dashboard showing data from Opportunities with Private OWD, but the dashboard should always reflect all records regardless of the viewer's data access. Which configuration achieves this?
  • Security implications of setting the dashboard running user to an admin with View All Data.
  • How report folder sharing interacts with org-wide sharing — specifically, whether a user with access to a report folder can run reports that return records beyond their own record-level sharing access.
  • How to control access to Salesforce Files (ContentDocument, ContentVersion) using sharing rules and which OWD settings govern file visibility.
  • How Content Library permissions (Viewer, Author, Administrator) differ from record-level file sharing.
  • When library-based access is appropriate over record-linked sharing for Salesforce Files.
  • A team needs access to a Salesforce File attached to an Opportunity but does not have access to the Opportunity itself. Which mechanism grants access to the file without opening up Opportunity access?
  • The three Territory Management model states (Planning, Active, Archived) and which state allows sharing to be generated.
  • How territory rules and manual assignments are applied to assign records to territories.
  • How Territory Management record access differs from role hierarchy-based access, and what access paths a record gets when assigned to a territory.
  • How territory sharing stacks with role hierarchy and OWD-based sharing — specifically, how a user in a territory that includes an Account gets access to that Account even if they are not the owner and the role hierarchy does not include the owner.
  • How access to Chatter posts, groups, and feeds is governed — specifically when a private Chatter group prevents non-members from seeing feed items on records they otherwise have access to.
  • How Knowledge article visibility is controlled through data categories, user profiles, and article types in Experience Cloud and internal portals.
  • How List Views can be restricted or shared using visibility settings and when this becomes a security concern if the underlying OWD is Private.
  • A compliance officer needs to see all email messages logged against Contacts in a Private OWD org. Which access controls apply to Email Message records and how should access be granted?
  • How access to Price Books, Products, and Assets is controlled and whether they follow the same record-level sharing model as custom objects.
  • Which mechanisms control access to external data objects (External Objects via Salesforce Connect) and how their sharing model differs from standard Salesforce objects.
  • Sharing recalculation behavior when OWD is changed — which operations trigger a recalculation, how long it can take, and the risk of record access being temporarily inconsistent.
  • Why deeply nested public groups or very large role hierarchies cause sharing recalculation timeouts.
  • How a large number of criteria-based sharing rules on a high-volume object creates recalculation performance risks and lock contention during bulk record updates.
  • Architectural patterns to mitigate sharing recalculation timeouts from deeply nested groups or large role hierarchies.
  • Performance trade-offs between using 'Public Read/Write' OWD (no recalculation, broader access) versus 'Private' OWD with sharing rules in a rapidly growing org.
  • How the 'Defer Sharing Calculation' feature works, when it should be used during data migration, and the risk of accessing records before recalculation completes.
  • When to prefer async processing for Apex managed sharing versus synchronous trigger-based sharing.
  • How Apex managed sharing at high volume (triggered on every record insert) can degrade performance compared to declarative sharing rules.
  • An org processes millions of records and needs complex cross-team sharing. Which sharing approach (declarative vs. programmatic) is most scalable and why?
  • Which Salesforce license types do not support role hierarchy-based record sharing and how that affects sharing architecture for external users.
  • High Volume Customer Portal (HVCP) license limitations: which sharing mechanisms are unavailable (no role, no sharing rules) and which alternatives (Apex sharing, account hierarchy) must be used.
  • Guest user license restrictions on record access: why guest users cannot be members of public groups or receive manual shares, and the compliant workaround.
  • A company wants to grant Partner Community users access to custom object records using criteria-based sharing rules. Which license type supports this and what are the restrictions?
  • How Salesforce Platform license differs from full Salesforce license in terms of object accessibility and whether sharing rules for standard objects can apply to Platform license users.
  • How the number of permission sets or permission set group assignments available differs by license type, and when this constraint affects the architect's ability to layer granular permissions.
  • How to use the 'Login As' feature and 'Record Access' page to validate record visibility for a specific user without modifying the sharing model.
  • How to query the Share object (e.g., AccountShare) directly in a sandbox to enumerate all sharing entries for a record and identify which sources contributed access to a given user.
  • How to write SOQL queries and Apex tests that validate sharing rules are correctly applied in a test context using Test.startTest() and runAs().
  • How Apex unit tests behave with respect to sharing when using System.runAs(): which sharing rules are evaluated, whether sharing table data carries over from test setup, and why test isolation can produce false positives.
  • A QA team needs to validate that a criteria-based sharing rule fires correctly when a specific field changes. What test strategy and tooling should an architect recommend?
  • When validating a complex sharing model post-migration, which combination of tools (Record Access page, SOQL on share objects, user login simulation) provides the most comprehensive verification?
  • How the Salesforce Event Monitoring logs (Login Event, Report Export) can be used to audit whether users accessed records they should not have been able to see.

Prepare for the Exam

Play Today's Certle
Back to track

Study Community

Ask questions and get the latest info from other Platform Sharing and Visibility Architect studiers. 593 members and growing.

Go to Discord

Choosing between page layout removal, FLS hidden, and record type restrictions to hide a set of fields from a specific user population in the UI.

Explainer

Learn More

Practice Question

Keep going

Next conceptLimitations of hiding data only at the UI layer when the data is still accessible via SOQL, API, or reports — and the recommended architectural fix.

Checklist progress

0/151 (0%)

0 of 151 concepts learned

Tip: You can filter concepts by status.

Prepare for the Exam

Play Today's Certle
Back to track

Study Community

Ask questions and get the latest info from other Platform Sharing and Visibility Architect studiers. 593 members and growing.

Go to Discord

Explainer

Salesforce provides three mechanisms to control field visibility in the user interface: page layouts, field-level security (FLS), and record types. Each applies at a different level of enforcement—page layouts control display on detail and edit pages only, FLS hides fields across the entire application including reports and the API, and record types limit picklist values and page layouts but do not restrict data access. Architects select the appropriate tool based on the scope of restriction required.

Core information
  • Page layouts control which fields appear on detail and edit pages for a specific record type and profile combination, but do not restrict field access in reports, search results, related lists, or the API.
More details and nuances
  • Use field-level security to prevent a user from accessing a field in any part of the application, including the API and reports; page layout removal alone cannot achieve this.