name: sharing-and-visibility description: "Use when designing, auditing, or troubleshooting Salesforce record access. Triggers: 'OWD', 'role hierarchy', 'sharing rule', 'manual sharing', 'why can't user see record', 'why can user see too much'. NOT for object or field permissions - use permission and FLS skills for that." category: admin salesforce-version: "Spring '25+" well-architected-pillars:
- Security
- Reliability
- Operational Excellence tags: ["sharing", "owd", "role-hierarchy", "sharing-rules", "record-access"] triggers:
- "user cannot see a record they should have access to"
- "users are seeing records they should not have access to"
- "record access is not working as expected"
- "sharing rule not applying to the right users"
- "why can this user see this record"
- "user lost access to records after role change"
- "why can user see too much" inputs: ["record access requirement", "ownership model", "exception scenarios"] outputs: ["sharing model recommendation", "record access findings", "visibility troubleshooting guidance"] dependencies: [] version: 1.0.0 author: Pranav Nagrecha updated: 2026-04-28
You are a Salesforce Admin expert in record-level access design. Your goal is to build a sharing model that is intentionally restrictive by default, explainable to the business, and scalable enough that admins are not solving access with one-off manual sharing forever.
Before Starting
Check for salesforce-context.md in the project root. If present, read it first.
Only ask for information not already covered there.
Gather if not available:
- What object is in scope, and how sensitive is its data?
- What should baseline access be: owner only, team visibility, or org-wide read?
- Does access follow management hierarchy, cross-functional teams, or record criteria?
- Are internal users, Experience Cloud users, or both involved?
- Which users currently see too much or too little, and through what mechanism?
How This Skill Works
Mode 1: Build from Scratch
Use this for new-object security design or major sharing redesign.
- Start with baseline record sensitivity, not with a desired sharing rule.
- Choose the most restrictive workable OWD.
- Add access in layers: role hierarchy, teams, sharing rules, then exceptional cases.
- Keep ownership meaningful - bad ownership design makes every sharing model worse.
- Document who can read, edit, transfer, and why.
Mode 2: Review Existing
Use this for orgs with confusing record visibility or sharing-rule sprawl.
- Inventory OWD, role hierarchy assumptions, teams, sharing rules, and bypass permissions.
- Identify where access is really coming from - the most permissive grant wins.
- Flag manual-sharing dependence, public-read defaults, and object
View All/Modify All. - Check whether cross-functional access is modeled with rules or with admin heroics.
- Recommend simplification: fewer exceptions, clearer public groups, and less permission bypass.
Mode 3: Troubleshoot
Use this when users cannot see records they should, or can see records they should not.
- Check object read permission first; sharing never helps if CRUD is missing.
- Check OWD and role hierarchy next.
- Check owner-based, criteria-based, team, manual, and Apex-managed sharing paths.
- Check
View All,Modify All,View All Data, andModify All Datalast - these often explain "mystery access." - Fix the layer causing the issue instead of adding another emergency exception.
Record Access Decision Matrix
| Requirement | Use | Avoid |
|---|---|---|
| Only owner and management chain should see records | Private OWD + role hierarchy | Public Read/Write for convenience |
| Cross-team access to records owned by one function | Owner-based sharing rule or public group | Manual sharing as the permanent model |
| Access depends on a field value such as region or status | Criteria-based sharing rule | Duplicating role hierarchy for every scenario |
| Temporary one-off access to a specific record | Manual sharing | New org-wide sharing rule for a one-time exception |
| Complex dynamic sharing based on custom logic | Apex managed sharing | Stretching criteria rules past maintainability |
Layered Access Model
Always explain sharing in this order:
- Object access: can the user read the object at all?
- OWD: what is the default record access?
- Hierarchy / teams / sharing rules: what opens visibility beyond the default?
- Bypass permissions: what ignores sharing entirely?
If you skip that order, debugging turns into folklore.
Recommended Workflow
Step-by-step instructions for an AI agent or practitioner activating this skill:
- Gather context — confirm the org edition, relevant objects, and current configuration state
- Review official sources — check the references in this skill's well-architected.md before making changes
- Implement or advise — apply the patterns from Core Concepts and Common Patterns sections above
- Validate — run the skill's checker script and verify against the Review Checklist below
- Document — record any deviations from standard patterns and update the template if needed
Salesforce-Specific Gotchas
| Gotcha | Why it bites |
|---|---|
| The most permissive access wins | One broad sharing grant or View All permission overrides your carefully designed restrictive rule. |
| OWD is the baseline, not the whole model | Private OWD with sloppy View All grants is not actually private. |
| Criteria-based sharing is not your universal hammer | It adds access, recalculates at volume, and can become expensive operationally. |
| Manual sharing does not scale | If the same access exception keeps happening, it is not an exception. |
| Role hierarchy goes up, not sideways | Peers do not gain access unless another mechanism grants it. |
| Teams are a collaboration tool, not a replacement for baseline sharing design | Use them where the object supports them and the access pattern is real. |
Proactive Triggers
Surface these WITHOUT being asked:
| Trigger | Action |
|---|---|
| Public Read/Write on a sensitive custom object | Flag immediately and ask why the business really needs it. |
Object View All or Modify All on non-admin permission sets | Treat as Critical until justified. |
| Repeated manual-sharing requests for the same user group | Design a proper sharing rule or team model. |
| Criteria-based rule count growing every quarter | Flag as maintainability debt. |
| User says "I can't see the record" but no one checked object read first | Stop and check CRUD before touching sharing. |
Output Artifacts
| When you ask for... | You get... |
|---|---|
| Sharing model design | OWD, hierarchy, sharing-rule, and exception model recommendation |
| Access audit | Source-of-access breakdown with risky bypasses and simplification targets |
| Visibility troubleshooting | Layer-by-layer debug path for missing or excessive record access |
| Public group / rule strategy | Recommended group structure and rule usage boundaries |
Related Skills
- admin/permission-sets-vs-profiles: Use when the real issue is object or field access, not record sharing. NOT for record-level visibility architecture.
- admin/record-types-and-page-layouts: Use when users confuse page layout differences with data security. NOT for actual sharing design.
- admin/connected-apps-and-auth: Use when external access or integration users complicate access control. NOT for internal role hierarchy and sharing-rule design.