Skip to main content Back CRM Cloud Mastery Sign up Create account

Sharing & Visibility Architect

Sharing and visibility as a design surface, decided end to end on one worked org.

  • Advanced
  • 37 lessons
  • 9 modules
  • English

Designed and created by Salesforce Expert

What you'll learn

  • Treat object and field permissions as architecture, not configuration
  • Set the record-access floor and open from it with intent
  • Design sharing for external users and for code
  • Secure data that is not a record: files, reports, dashboards and more
  • Defend a complete sharing design, and sit the Sharing and Visibility exam

Course content

9 sections · 37 lectures

The architect's question 3 lectures
  1. 1.1 Nine weeks to answer a question about March
  2. 1.2 Two-fifths of the exam is one question
  3. 1.3 The decision record: writing a sharing choice down so it can be defended later
Object permissions as a design surface 4 lectures
  1. 2.1 Profiles, permission sets, groups and muting — the entitlement model you design
  2. 2.2 View All, Modify All, and the two permissions that outrank your entire sharing model
  3. 2.3 Object permission or record access? The question that decides whether you write a sharing rule
  4. 2.4 An entitlement model that survives five years of joiners, movers and leavers
Fields, sensitive data, and enforcement 5 lectures
  1. 3.1 Field-level security is the only layer with no sharing escape hatch
  2. 3.2 Hiding data at the user interface level is not security, and the blueprint asks for it anyway
  3. 3.3 PCI, PII and HIPAA-shaped requirements: classify first, then design the control to the class
  4. 3.4 Encryption and masking answer a different question from visibility
  5. 3.5 The programmatic solution the blueprint names — user mode, sharing keywords, stripping the inaccessible
The record-access floor 4 lectures
  1. 4.1 Org-wide defaults are the one decision you cannot take back cheaply
  2. 4.2 Object relationships are a sharing decision, and implicit sharing is the part you cannot configure
  3. 4.3 Record access overrides: ownership, the hierarchy grant, and the permissions that ignore both
  4. 4.4 Restriction rules and scoping rules — one subtracts, the other only tidies
Opening access deliberately 5 lectures
  1. 5.1 The role hierarchy is a vertical instrument and most requirements are not vertical
  2. 5.2 Sharing rules, and the recalculation you are signing up for
  3. 5.3 Groups, queues and teams — three ways to name a set of people, and the question that picks
  4. 5.4 Enterprise Territory Management: a second hierarchy, and the cases where it is the right answer
  5. 5.5 Manual shares, the exception layer, and what happens the day the owner changes
External users and programmatic sharing 4 lectures
  1. 6.1 The external model is a second model: external org-wide defaults, portal roles, and the licence that decides it
  2. 6.2 Sharing sets and share groups — the mechanism that exists because roles do not scale to a portal
  3. 6.3 Apex managed sharing: the share object, the row cause, and the maintenance you have just bought
  4. 6.4 When the answer is not sharing at all — a service layer, a different interface, or not putting the data there
Access to data that is not a record 5 lectures
  1. 7.1 Sixteen marks rest on one sentence: everything in the org that has no org-wide default
  2. 7.2 Files, attachments and libraries — the sharing model nobody draws
  3. 7.3 Reports, dashboards, folders and running users, and analytics with a security model of its own
  4. 7.4 Knowledge, data categories, list views, and the metadata surfaces you grant rather than share
  5. 7.5 The data with no sharing model at all: external objects, big objects and events
Implications of the choice 5 lectures
  1. 8.1 Sharing at volume: the sharing tables, recalculation, and group membership locking
  2. 8.2 Skew — ownership, lookup and account data — and the load that runs all weekend
  3. 8.3 The licence decides the model before you do
  4. 8.4 Testing a sharing model: what a unit test proves, and the harness that answers an inspector
  5. 8.5 Least privilege as a design constraint, and the access review you can actually run
Vellacourt, decided end to end 2 lectures
  1. 9.1 The requirements as they arrive, and the four conflicts buried inside them
  2. 9.2 The model, decision by decision, with every rejected alternative named

Requirements

  • CORE-140 Security, Sharing & Visibility
  • Working experience of a real org's security model

Description

The architect's version of the sharing model. Object permissions treated as a design surface, fields and sensitive data and where enforcement actually happens, the record-access floor, opening access deliberately, external users and programmatic sharing, and access to data that is not a record at all.

Every decision is then taken end to end on one org — Vellacourt — so the trade-offs are visible rather than theoretical. It covers the Platform Sharing and Visibility Architect blueprint.

Who this course is for

  • Architects and senior administrators who own access design.

Skills you'll practise

Sharing architectureRecord accessField-level securityApex sharingExternal usersSecurity design

Related reading