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

  • 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
  • Choosing Read, Edit, or no access on a field for a user group
  • Page layout and field-level security precedence when settings conflict
  • View All Fields and the field-level limits of override permissions
  • 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
  • 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
  • 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

Given a set of conditions, recommend the appropriate organization-wide defaults to restrict access to records

0/7

  • 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

Given a set of conditions, recommend a solution that leverages the role hierarchy to support the record access requirements

0/5

  • 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

Given a set of conditions, determine how sharing rules can be implemented to support the record access requirements

0/8

  • 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

Given a set of conditions, determine how groups can support the record access requirements

0/4

  • 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

Given a set of conditions, determine how teams can support the record access requirements

0/7

Account team member access to accounts and related child records

Learn this concept
Unseen

Account teams versus sharing rules and manual sharing for per-account access

Learn this concept
Unseen

Account team retention when account ownership changes

Learn this concept
Unseen

Opportunity teams for deal-level collaboration and access

Learn this concept
Unseen

Case team roles and the case access they grant

Learn this concept
Unseen

Predefined case teams added through assignment rules

Learn this concept
Unseen

Partner and customer site users on account and case teams

Learn this concept
Unseen

Given a set of conditions, determine the correct object relationships that support record access sharing requirements

0/5

  • 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

Given a set of conditions, determine how programmatic sharing supports the record access requirements

0/6

  • 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

Given a set of conditions, determine what sharing mechanism is appropriate to share records with External Users

0/9

  • 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

Given a set of conditions, determine how record access overrides support the record access requirements

0/3

  • 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. 662 members and growing.

Go to Discord
  1. Platform Sharing and Visibility Architect Checklist
  3. Access to Records

Account team retention when account ownership changes

Explainer

Learn More

Practice Question

Keep going

Next conceptOpportunity teams for deal-level collaboration and access

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. 662 members and growing.

Go to Discord
Close
  1. Platform Sharing and Visibility Architect Checklist
  3. Access to Records
Account team retention when account ownership changes

Explainer

Learn More

Practice Question

Keep going

Next conceptOpportunity teams for deal-level collaboration and access

Explainer

An account team is a group of users whom the account owner adds to an account so they can work on it, and each team member record grants those users access to the account and its related records. When an account's owner changes, a Keep account team option exists, but whether each team member stays on the team depends on who originally added that member.
Core information
  • An account team member record is one of several ways a user gets access to an account and its related records. The others are profiles, org-wide defaults (OWD), the role hierarchy, sharing rules and manual sharing. Account teams must be enabled by a Salesforce admin and are available in Enterprise, Performance, Unlimited and Developer Editions.
More details and nuances
  • Being able to add team members does not mean those members will survive an owner change. A user in a public group with sharing-rule Edit access can add team members, but those members are removed at the next ownership change.

Explainer

An account team is a group of users whom the account owner adds to an account so they can work on it, and each team member record grants those users access to the account and its related records. When an account's owner changes, a Keep account team option exists, but whether each team member stays on the team depends on who originally added that member.
Core information
  • An account team member record is one of several ways a user gets access to an account and its related records. The others are profiles, org-wide defaults (OWD), the role hierarchy, sharing rules and manual sharing. Account teams must be enabled by a Salesforce admin and are available in Enterprise, Performance, Unlimited and Developer Editions.
More details and nuances
  • Being able to add team members does not mean those members will survive an owner change. A user in a public group with sharing-rule Edit access can add team members, but those members are removed at the next ownership change.