Cert++
  1. Home
  3. Platform Sharing and Visibility Architect

Platform Sharing and Visibility Architect

Checklist progressProgress

0/131Learned

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
  • Slack Administrator

Checklist progressProgress

0/131Learned

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

0/10

  • Object permissions, record sharing and field-level security as layered access
  • Profiles, permission sets and permission set groups for object and field access
  • Object CRUD permission combinations for a job function
  • Additive permissions, revoking access and permission set group muting
  • View All and Modify All Records versus sharing rules for broad access
  • Object-level View All and Modify All versus View All Data and Modify All Data
  • View All Records reach into standard and custom child objects
  • Availability limits of View All and Modify All permissions
  • Delegated administration versus broad admin permissions for managing access
  • Least-privilege object access for integration and deployment users

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

0/3

Choosing Read, Edit, or no access on a field for a user group

Learn this concept
Unseen

Page layout and field-level security precedence when settings conflict

Learn this concept
Unseen

View All Fields and the field-level limits of override permissions

Learn this concept
Unseen

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

0/8

  • Field-level security versus page layouts for hiding sensitive fields
  • Record types and page layout assignment for role-specific record views
  • Dynamic Forms and Lightning page component visibility rules
  • Tab and app visibility versus object permissions
  • List view visibility and scoping rules versus restriction rules
  • Page layout and record type controls versus what the API enforces
  • Classic Encryption masking and View Encrypted Data for partial display
  • Experience Cloud personal information visibility for external and guest users

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

0/7

  • Field-level security versus encryption for sensitive fields
  • Classic Encryption versus Shield field-level and Database Encryption
  • Encrypting files, attachments, Chatter and search indexes
  • Deterministic versus probabilistic encryption schemes
  • Shield Platform Encryption tradeoffs and feature limitations
  • Shield key management and rotation options
  • Session-based and network conditions on sensitive data access

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

0/8

  • Declarative platform access model versus custom access logic in Apex controllers
  • Standard UI data frameworks versus custom Apex controllers for security enforcement
  • Choosing with sharing, without sharing, or inherited sharing for Apex classes
  • Record sharing keywords versus object and field permission enforcement in Apex
  • User mode versus system mode database operations in Apex
  • Security.stripInaccessible and describe checks for graceful enforcement
  • When system-mode code may bypass CRUD, FLS, and sharing
  • Experience Cloud personal information visibility settings in Apex
  • Choosing an object's org-wide default from its most restricted user
  • Org-wide defaults combined with object permissions
  • Controlled by Parent OWD for contacts, activities and detail objects
  • Internal versus external org-wide defaults for authenticated site users
  • User record visibility with the User OWD and user sharing rules
  • Tightening the OWD versus restriction rules to narrow record visibility
  • Consequences of changing an existing object's OWD
  • Record access inherited through the role hierarchy
  • Lateral and cross-branch access the role hierarchy does not grant
  • Grant Access Using Hierarchies for confidential custom objects
  • Roles modeled on data access levels rather than the org chart
  • Territory management versus the role hierarchy and account teams
  • Sharing rules as additive exceptions to org-wide defaults
  • Owner-based versus criteria-based sharing rules
  • Choosing the share-with category for a sharing rule
  • Account sharing rules and access to related child records
  • Criteria-based sharing rule field limitations and workarounds
  • Sharing rules versus manual sharing for record-level exceptions
  • Sharing rule maintenance and recalculation behaviour
  • Sharing rule volume limits per object
  • Public groups for cross-functional record access
  • All Internal Users and other system-defined groups as sharing targets
  • Manager groups for sharing along the user manager chain
  • Queues for shared ownership versus public groups for sharing
  • Account team member access to accounts and related child records
  • Account teams versus sharing rules and manual sharing for per-account access
  • Account team retention when account ownership changes
  • Opportunity teams for deal-level collaboration and access
  • Case team roles and the case access they grant
  • Predefined case teams added through assignment rules
  • Partner and customer site users on account and case teams
  • Master-detail versus lookup for child record access
  • Junction object access in many-to-many relationships
  • Implicit parent access to accounts from child records
  • Role-level opportunity, case and contact access for account owners
  • Built-in sharing gaps on custom relationships to accounts
  • Declarative sharing versus Apex managed sharing for record-specific access
  • Access levels grantable through Apex share records
  • Apex sharing reasons and share persistence after ownership changes
  • Recalculating Apex managed sharing after sharing model changes
  • Sharing keywords for enforcing record access in Apex classes
  • Group-targeted versus user-targeted Apex managed shares at scale
  • Matching external sharing mechanisms to Experience Cloud license types
  • Built-in implicit sharing for site and portal users
  • Role-based sharing for Partner and Customer Community Plus users
  • Internal-only versus portal-inclusive role targets in sharing
  • Super user access for partner and customer site users
  • Account relationship data sharing rules between partner accounts
  • Sharing sets for high-volume Experience Cloud site users
  • Share groups versus sharing rules for records owned by high-volume users
  • Guest user sharing rules for unauthenticated site visitors
  • Sharing-based access versus override permissions for a user population
  • Delegated record administration tasks that require Modify All
  • Auditing and troubleshooting users who bypass sharing through overrides
  • Access to objects outside the record sharing model
  • Enhanced folder sharing for report and dashboard folders
  • Report and dashboard user permissions for building, exporting and managing
  • Report folder access versus underlying record visibility
  • Dashboard running user versus dynamic dashboards
  • External user access to reports and dashboards by license type
  • List view visibility and sharing
  • File sharing settings and file access levels
  • Chatter group visibility types and external members
  • File visibility through record and group feed posts
  • File owner controls to stop resharing or revoke access
  • Content deliveries and public links for external file sharing
  • Salesforce CRM Content libraries and library permissions
  • Knowledge data category visibility settings
  • Custom permissions for gating custom processes and apps
  • Big object access controls
  • Organization-wide default changes and sharing recalculation overhead
  • Group-based sharing versus individual-user shares at scale
  • Role hierarchy and nested group maintenance cost
  • Controlled by Parent versus independently shared child objects at scale
  • View All permissions versus sharing for broad-access and integration users
  • Ownership data skew and the role placement of high-volume record owners
  • Account data skew and parent-child lock contention
  • Deferred sharing calculations for large data loads and realignments
  • External roles per account and role growth at scale
  • High-volume external licenses for very large external user populations
  • User, permission set and feature licenses as limits on grantable access
  • Salesforce Platform versus Salesforce license for standard object access
  • Chatter-only and identity-only licenses in a sharing design
  • Partner Community license fit for channel partner access
  • Customer Community versus Customer Community Plus for record sharing
  • Record access limits for high-volume external users
  • Sharing set access mappings and their boundaries
  • Persona-based sharing test plan with positive and negative cases
  • Login As another user to validate what a persona sees
  • Sharing button and Sharing Hierarchy for explaining record access
  • User access summaries for reviewing a user's effective permissions
  • System.runAs for testing record visibility in Apex tests
  • Permission-based tests for object and field access by user
  • UserRecordAccess versus share records for verifying access programmatically
  • Validating custom Apex, controllers and flows against the sharing model

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.

Go to Discord
  1. Platform Sharing and Visibility Architect Checklist
  3. Permissions to Standard Objects, Custom Objects, and Fields

Choosing Read, Edit, or no access on a field for a user group

Explainer

Learn More

Practice Question

Keep going

Next conceptPage layout and field-level security precedence when settings conflict

Checklist progress

0/131 (0%)

0 of 131 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.

Go to Discord
Close
  1. Platform Sharing and Visibility Architect Checklist
  3. Permissions to Standard Objects, Custom Objects, and Fields
Choosing Read, Edit, or no access on a field for a user group

Explainer

Learn More

Practice Question

Keep going

Next conceptPage layout and field-level security precedence when settings conflict

Explainer

Field permissions, also called field-level security (FLS), control whether a user can see and edit each field on an object, so users can work with an object while its sensitive fields stay protected. For each field and user group, the architect picks one of three levels: Read and Edit, Read only, or no access. FLS is the only reliable way to keep a field away from a user, because it applies across the whole app and not just on page layouts.
Core information
  • FLS is the second layer of data access. Object permissions come first, and record-level access is the third layer. FLS lets you give users an object but limit individual fields, such as hiding a candidate's social security number without hiding the Candidate object.
More details and nuances
  • When page layout and FLS settings disagree, the more restrictive one applies. A field marked required on the layout but set to read-only in FLS stays read-only. The recommended pattern is to restrict fields with FLS and use page layouts only to organize fields, which also means fewer layouts to maintain.

Explainer

Field permissions, also called field-level security (FLS), control whether a user can see and edit each field on an object, so users can work with an object while its sensitive fields stay protected. For each field and user group, the architect picks one of three levels: Read and Edit, Read only, or no access. FLS is the only reliable way to keep a field away from a user, because it applies across the whole app and not just on page layouts.
Core information
  • FLS is the second layer of data access. Object permissions come first, and record-level access is the third layer. FLS lets you give users an object but limit individual fields, such as hiding a candidate's social security number without hiding the Candidate object.
More details and nuances
  • When page layout and FLS settings disagree, the more restrictive one applies. A field marked required on the layout but set to read-only in FLS stays read-only. The recommended pattern is to restrict fields with FLS and use page layouts only to organize fields, which also means fewer layouts to maintain.