Salesforce Platform Sharing and Visibility Architect

Object and field permissions are the first gate. You build them with permission sets and groups, use muting where a group is too broad, and understand what View All and Modify All do to the layers below.

• Profiles and permission sets, and moving toward permission sets
• Permission set groups and muting
• Create, read, edit and delete in practice
• View All and Modify All
• Field-level security rules
• Reviewing effective access for a user

You build An object and field permission design for a set of roles using permission sets.

A hidden field is not always a protected field. You compare layouts, dynamic forms, record types and field security, and find where data still leaks through reports, search and the API.

• Page layouts against field-level security
• Dynamic forms and conditional visibility
• Record types and what they hide
• Where hidden data leaks: reports, search and API
• Report and list view visibility
• Choosing the right control to hide data

You build A visibility review that finds and closes the leaks for one sensitive field.

Card, personal and health data carry legal weight. You classify sensitive fields, choose encryption and masking, limit who can export or view them, and keep protection in place outside production.

• Classifying sensitive data
• Encryption options and their effect on features
• Masking and tokenizing data
• Limiting export and bulk access
• Protecting data in sandboxes
• Monitoring access to sensitive fields

You build A protection plan for payment card, personal and health data in one org.

Code runs with powers a user may not have. You decide how Apex and components should treat sharing and field security, using sharing keywords, access checks and user-mode queries so custom code does not undo the model.

• With, without and inherited sharing
• Checking object and field access in Apex
• Stripping inaccessible fields
• User-mode queries and DML
• Securing Lightning and Visualforce data access
• Testing code under different users

You build A secure Apex service class tested under users with different access.

Record access begins with the defaults and the hierarchy above them. You set defaults per object, design a role hierarchy that matches how access should flow, and know when the hierarchy is the wrong tool.

• Org-wide defaults per object
• Controlled by parent and its effects
• Grant access using hierarchies
• Role hierarchy design
• Ownership as an access grant
• When the hierarchy hurts

You build An org-wide default and role hierarchy design for a multi-team company.

Rules open records to people outside the owner’s line. You compare owner-based and criteria-based rules, public groups, queues, record teams and territory management, and pick the least costly one for each case.

• Owner-based sharing rules
• Criteria-based sharing rules
• Public groups and queues
• Account, opportunity and case teams
• Territory management for access
• Manual sharing and its limits

You build A sharing design that opens records through rules, groups and teams, with each choice explained.

Some access depends on logic that rules cannot express. You write Apex managed sharing using share objects and sharing reasons, understand implicit sharing, and plan recalculation when the logic changes.

• Share objects and access levels
• Sharing reasons and row causes
• Writing Apex managed sharing
• Implicit sharing and what it grants
• Recalculation and sharing batch jobs
• Testing programmatic sharing

You build An Apex managed sharing solution with a recalculation job and tests.

Partners and customers need access without seeing everyone else’s data. You set external defaults, use share groups, sharing sets and super users, and handle guest user rules and high-volume users.

• External org-wide defaults
• Sharing sets and share groups
• Super user access for partners
• High-volume portal users and their sharing
• Guest user access rules
• Testing the external view

You build An external sharing design for customers and partners on one site.

Not everything people see is a standard or custom object record. You control access to report and dashboard folders, files and libraries, Chatter, and configuration data, so a gap outside the object model cannot undo a careful design.

• Report and dashboard folder access
• Files, libraries and sharing of files
• Chatter groups and feed access
• Email templates and document folders
• Configuration data and who can read it
• Reviewing the non-record data in an org

You build An access review of non-record data in one org, with gaps closed.

A sharing design that works for a small team can stall for a very large one. You judge how groups, hierarchy depth and skew affect recalculation, which license limits apply, and how to test access before launch.

• Sharing recalculation and group membership cost
• Role depth and data skew
• Deferring sharing calculations during loads
• License limits that restrict access options
• Testing access with representative users
• Reviewing a security model before launch

You build A scale and test plan that proves a sharing design before it goes live.

Take a scenario with internal, partner and customer users, sensitive data and high volumes, and design the full model. You defend each choice against the questions a security reviewer would ask.

• Reading the scenario for access requirements
• Designing permissions and record access
• Handling sensitive data and external users
• Checking scale and testing
• Presenting and defending the design

You build A complete security and visibility design for one scenario, with its test plan.