You don't have access to this record. Ask your administrator for help.

A sales rep tries to open an Opportunity her manager forwarded to her by email. She clicks the link and sees a page that reads "You don't have access to this record. Ask your administrator for help." The Opportunity belongs to her team's region. She has owned similar Opportunities before. The manager is on vacation. The deal is supposed to close this week. She submits a help ticket and waits.

What the platform is checking

Salesforce enforces a layered access model. To open a record, the user needs to satisfy several conditions in sequence: their profile must allow read access to the object, their role and sharing rules must give them access to that specific record, the record's owner must have shared the record (explicitly or through inheritance), and any active sharing settings (organization-wide defaults, criteria-based sharing rules, manual sharing) must permit the access. If any layer denies access, the platform shows the "no access" page.

The message is intentionally generic. Telling the user "you fail rule X" would leak information about the data model and the sharing strategy. The page redirects them to ask their administrator, who has the tooling to diagnose the specific layer that denied access.

The diagnosis sits on the admin side. The Sharing Settings page, the user's role and profile, the record's owner, and the active sharing rules together tell the story. A common cause is that the record's owner is in a different role hierarchy branch and the organization-wide default is Private; another common cause is a recently changed sharing rule that did not propagate yet; a third common cause is field-level security that hides the record from the user's view (in which case the underlying read access exists but the UI cannot render the record).

The page also fires for records that have been deleted but not yet purged. The Recycle Bin holds them, and a deep link to the record id returns no-access because the record is not in active state.

The broken example

The scenario from the opening:

User: Sarah Chen, sales rep, Western Region
Profile: Sales User
Role: Sales Rep - West

Record: Opportunity O-2024-1175
Owner: Mike Torres (also Sales Rep - West, but in a different territory)
Account: Goldstar Industries
Stage: Negotiation/Review
Amount: $450,000

Organization-Wide Default for Opportunity: Private
Active sharing rules:
- "Western Region Sharing" shares Opportunities owned by Sales Rep - West with Sales Rep - West (read/write).
- "Manager Visibility" shares Opportunities with managers up the role hierarchy.

Sarah's role grants her access to Opportunities owned by other Western Region reps through the "Western Region Sharing" rule. She should have access. The system says she does not.

Investigation by the admin reveals the cause. The "Western Region Sharing" rule was recently edited to share with role "Sales Rep - West (No Subordinates)" instead of role "Sales Rep - West". Sarah's role assignment uses the with-subordinates form. The rule no longer matches her role exactly. The sharing recalculation has finished. The record is no longer shared with her.

A second shape: a record owned by an inactive user. When an owner is deactivated, the records they own remain in place but the sharing rules that share their records often have edge cases. If the rule "shares with the user's manager" relies on the manager being active in a specific role and that role changed, the rule no longer applies.

A third shape: a record in a different Account hierarchy. An Opportunity owned by a partner organization's user (in a partner community) is normally invisible to internal users unless an explicit sharing rule grants access. A new partner deal can land in production without the right sharing configured.

A fourth shape: a record on which the user has read access to the underlying record but no read access to a critical field. The UI may show "no access" when the user cannot read the Name field or another field required for display, even though the record itself is accessible.

The fix, three paths

Identify the layer that denied access. The first step is for the admin to use the Sharing Hierarchy tool on the record. The tool shows every user and group that has access to the record and the reason for each (owner, role hierarchy, sharing rule, manual share, team membership). The same tool can be inverted: from the user, show which sharing rules apply to them on the Opportunity object.

In Setup, open the Opportunity object's record, click "Sharing" in the action menu, and review the list. If the target user does not appear, find the rule that should have included them and inspect why it does not.

For Sarah's case, the admin would see that no rule shares this record with her. The rule that should share it (Western Region Sharing) does not match her role because the rule's role parameter changed. The fix is to either update the rule's role to the correct form, manually share the record with Sarah, or have the record reassigned to an owner whose records are reliably shared.

Add a sharing rule, criteria-based sharing rule, or manual share. The right scope of fix depends on whether the problem affects only this one record or a class of records.

For one record, a manual share via the Sharing button on the record gives Sarah immediate access:

public static void shareWithUser(Id recordId, Id userId, String accessLevel) {
    OpportunityShare share = new OpportunityShare();
    share.OpportunityId = recordId;
    share.UserOrGroupId = userId;
    share.OpportunityAccessLevel = accessLevel; // 'Read' or 'Edit'
    insert share;
}

For a class of records, the sharing rule is the right place. Updating the existing "Western Region Sharing" rule to match the right role grants access to every affected record at once.

Use the record-access methods to write defensive Apex. Apex code that uses the standard share table needs to handle the case where a user has access through some other mechanism (sharing rule, manual share, role inheritance). The UserRecordAccess object reveals what access a user actually has:

UserRecordAccess access = [
    SELECT RecordId, HasReadAccess, HasEditAccess
    FROM UserRecordAccess
    WHERE UserId = :userId
    AND RecordId = :opportunityId
];
if (!access.HasReadAccess) {
    // proactively share or notify
}

The query lets server-side code check access before linking to a record, which avoids sending users to the "no access" page in the first place.

The fixed example

The corrected sharing rule restores access for Sarah and the rest of the Western Region team:

Sharing Rule: Western Region Sharing
Owned By: Role: Sales Rep - West
Shared With: Role and Subordinates: Sales Rep - West
Access Level: Read/Write

After saving, Salesforce queues a sharing recalculation. Within minutes (or a few hours for large data volumes), the recalculation completes and Sarah can open Opportunity O-2024-1175. The other reps in her region who were silently locked out also regain access.

For Sarah's immediate need, the admin creates a manual share that gives her access before the recalculation completes:

insert new OpportunityShare(
    OpportunityId = 'O-2024-1175 Id here',
    UserOrGroupId = sarahsUserId,
    OpportunityAccessLevel = 'Edit',
    RowCause = 'Manual'
);

Sarah can open the record within seconds. The manual share remains in place after the rule fix and does not interfere with the rule-based access.

Edge case: organization-wide defaults

The organization-wide default (OWD) for an object sets the floor of access. With OWD set to Private, users see only records they own or that have been shared with them. With OWD set to Public Read Only, all users see all records (read-only). With OWD set to Public Read/Write, everyone can edit everything.

Tightening the OWD from Public to Private exposes "no access" errors on records that were previously visible. Loosening it makes them go away but breaks the team's data governance. The OWD decision is a strategic choice; it should not be changed lightly.

Edge case: role hierarchy promotion

A user promoted to a higher role typically gains access to records owned by users below them in the hierarchy through "Grant Access Using Hierarchies." When the promotion happens, Salesforce recalculates sharing. The recalculation can take minutes to hours depending on data volume. During the lag, the user may see "no access" errors on records they should see.

Edge case: criteria-based sharing rules

A criteria-based sharing rule shares records that match a formula (for example, share Opportunities where Region__c = 'West'). If the formula evaluates differently after a field value changes, the rule's outcome changes too. A record edit that changes the region from "West" to "South" can remove access for the original team. This is intended behavior but can produce surprise "no access" errors.

Edge case: account team and opportunity team members

Account teams and opportunity teams provide an alternative sharing mechanism. A user added to the team gets access through the team membership, separate from sharing rules. If a team member is removed (intentionally or accidentally), their access ends. A team membership audit reveals these cases.

Edge case: external user (community) access

A user in an external community has sharing rules separate from internal users. Sharing sets and external sharing rules control what community users can see. Misconfiguration here typically affects partner or customer users only, not internal staff.

Defensive habits

Document the sharing model. A diagram of the organization-wide defaults, role hierarchy, sharing rules, and team memberships clarifies the layers for new admins and for incident responders.

Test sharing changes in a sandbox before production. A sharing rule edit that looks innocuous can have wide effects when data volume is large.

Use the Sharing Settings page's "Recalculate" action when a rule change is needed urgently. The button forces an immediate recalculation rather than waiting for the scheduled cycle.

Monitor for "no access" complaints. A weekly review of help tickets tagged "access" surfaces systemic issues before they affect the next quarter's deals.

Use the UserRecordAccess object in Apex to check access before linking. A button that opens a record can disable itself when the current user has no access, with a helpful tooltip.

Test patterns

A test that verifies sharing for a specific user-record pair:

@IsTest
static void salesRepCanAccessSharedOpportunity() {
    Profile p = [SELECT Id FROM Profile WHERE Name = 'Standard User' LIMIT 1];
    User salesRep = new User(
        ProfileId = p.Id,
        Alias = 'srep',
        Email = 'salesrep@example.com',
        Username = 'salesrep' + DateTime.now().getTime() + '@example.com',
        FirstName = 'Sarah',
        LastName = 'Chen',
        TimeZoneSidKey = 'America/Los_Angeles',
        LocaleSidKey = 'en_US',
        EmailEncodingKey = 'UTF-8',
        LanguageLocaleKey = 'en_US'
    );
    insert salesRep;

    Account a = new Account(Name='Goldstar Industries');
    insert a;
    Opportunity o = new Opportunity(
        Name='Big Deal', AccountId=a.Id, StageName='Negotiation/Review',
        CloseDate=Date.today().addDays(7), Amount=450000
    );
    insert o;

    insert new OpportunityShare(
        OpportunityId = o.Id,
        UserOrGroupId = salesRep.Id,
        OpportunityAccessLevel = 'Edit',
        RowCause = 'Manual'
    );

    System.runAs(salesRep) {
        UserRecordAccess access = [
            SELECT HasReadAccess, HasEditAccess
            FROM UserRecordAccess
            WHERE UserId = :salesRep.Id AND RecordId = :o.Id
        ];
        System.assert(access.HasReadAccess, 'Sales rep should have read access via manual share');
    }
}

The test creates a user, creates a record, shares the record manually, and confirms the share works. Adapting the same pattern to test sharing-rule outcomes requires creating users in matching roles and waiting for sharing recalculation (which the test framework handles automatically).

Diagnosing in production

When a user reports a "no access" error:

1. Capture the user id and the record id.
2. Run the Sharing Hierarchy on the record from the admin UI.
3. Compare the actual access list with the expected sharing rules.
4. Identify the discrepancy (missing rule, wrong role, deactivated owner).
5. Apply the right fix at the right scope.
6. Confirm the user can now open the record.

Most cases resolve within fifteen minutes once the admin has the record id and the user id in hand.

Anti-pattern: granting blanket admin access

A reflex fix is to elevate the user to a higher profile or to add them to the System Administrator profile. This grants far more than the user needs and creates auditability problems. The right fix is targeted: a manual share, a sharing rule update, or a role change that addresses the specific gap.

Anti-pattern: changing the OWD to fix one user

Loosening the organization-wide default from Private to Public Read removes the "no access" error for one user and for everyone else. The exposure widens significantly. A targeted sharing rule is almost always the right answer.

Quick recovery checklist

1. Capture user id and record id.
2. Open the Sharing Hierarchy.
3. Identify the missing access layer.
4. Apply the smallest fix that restores access (manual share, rule update, role change).
5. Document the cause in the help ticket.
6. Confirm with the user.

The error itself is a security boundary doing its job. The recovery is about restoring the right access without weakening the boundary.

Further reading from Salesforce

• Salesforce Help: Sharing and Visibility
• Salesforce Help: Sharing Rules
• Apex Developer Guide: UserRecordAccess SObject
• Architect: Sharing and Visibility Architect Guide
• Trailhead: Data Security