Sharing And Visibility

---
name: sharing-and-visibility
description: "Use when choosing between Salesforce record-access mechanisms or reviewing the access model end to end. Trigger keywords: OWD, org-wide defaults, record access model, sharing architecture, why can user see too much. NOT for sharing rules - use admin/sharing-rules. NOT for role hierarchy - use admin/role-hierarchy-design."
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"
  - "view all data used as the sharing model"
  - "private tasks owned by inactive 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-08-14
---

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.

1. Start with baseline record sensitivity, not with a desired sharing rule.
2. Choose the most restrictive workable OWD.
3. Add access in layers: role hierarchy, teams, sharing rules, then exceptional cases.
4. Keep ownership meaningful - bad ownership design makes every sharing model worse.
5. Document who can read, edit, transfer, and why.

### Mode 2: Review Existing

Use this for orgs with confusing record visibility or sharing-rule sprawl.

1. Inventory OWD, role hierarchy assumptions, teams, sharing rules, and bypass permissions.
2. Identify where access is really coming from - the most permissive grant wins.
3. Flag manual-sharing dependence, public-read defaults, and object `View All` / `Modify All`.
4. Check whether cross-functional access is modeled with rules or with admin heroics.
5. 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.

1. Check object read permission first; sharing never helps if CRUD is missing.
2. Check OWD and role hierarchy next.
3. Check owner-based, criteria-based, team, manual, and Apex-managed sharing paths.
4. Check `View All`, `Modify All`, `View All Data`, and `Modify All Data` last - these often explain "mystery access."
5. 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:

1. **Object access**: can the user read the object at all?
2. **OWD**: what is the default record access?
3. **Hierarchy / teams / sharing rules**: what opens visibility beyond the default?
4. **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:

1. Gather context — confirm the org edition, relevant objects, and current configuration state
2. Review official sources — check the references in this skill's well-architected.md before making changes
3. Implement or advise — apply the patterns from Core Concepts and Common Patterns sections above
4. Validate — run the skill's checker script and verify against the Review Checklist below
5. 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.