What is the impact of enforcing sharing rules i.e. using "with sharing" keyword on apex class?

Declaring a class with sharing instructs the Apex runtime to apply the running user’s record-level sharing to all SOQL queries and DML inside that class. Records the user wouldn’t see in the UI are excluded from query results; DML on records they can’t edit raises a System.DmlException with the appropriate insufficient-access error. It does not enforce field-level security or CRUD — those are separate enforcement mechanisms.

What with sharing actually enforces

The keyword is laser-focused on record visibility, not field or object permissions.

Concrete effects

SOQL

A SOQL query in a with sharing class returns only records the running user is entitled to see per the platform’s sharing rules.

public with sharing class CaseService {
    public List<Case> myAccessibleCases() {
        // Returns ONLY cases the running user can see —
        // their owned cases, cases shared with them, cases visible via hierarchy.
        return [SELECT Id, Subject FROM Case WHERE Status = 'New'];
    }
}

The same query in a without sharing class would return every “New” case in the org.

DML

If the user lacks edit access to a record, the DML raises an exception:

public with sharing class CaseService {
    public void closeCase(Id caseId) {
        Case c = new Case(Id = caseId, Status = 'Closed');
        update c;  // Throws DmlException if user lacks Edit on this case
    }
}

You can catch the exception and translate it to a user-friendly error.

Aggregate functions

COUNT(), SUM(), AVG() honor sharing — the aggregate is computed over records the user can see, not the entire table.

What with sharing does not do

• Doesn’t grant access — it can only restrict. A user without access stays without access.
• Doesn’t replace FLS checks — a user with no FLS read on a field can still see it via SELECT in with sharing Apex, because the query level doesn’t enforce FLS. Use Security.stripInaccessible(AccessType.READABLE, records) or WITH USER_MODE (modern equivalent) to enforce FLS in code.
• Doesn’t replace CRUD checks — similar story. The class can INSERT even if the user lacks Create on the object, unless you enforce it via Schema.sObjectType.X.isCreateable() or WITH USER_MODE.
• Doesn’t apply to inner classes by inheritance — inner classes inherit from their outer class’s keyword.

When to choose with sharing

Default to with sharing (or inherited sharing) for:

• Controllers behind LWCs (@AuraEnabled).
• REST endpoints (@RestResource).
• Triggers’ helper classes when the trigger represents user-initiated activity.
• Any class executed in a user context where the user shouldn’t see beyond their normal data.

Switch to without sharing only for explicit, audited bypasses (Apex sharing logic, aggregations across data the user can’t see, integration plumbing).

Performance impact

Enforcing sharing has a non-trivial cost on large data volumes — the query optimizer has to filter against the user’s effective sharing set, which involves an extra join with the share table. For high-volume read paths, profile carefully and consider:

• Indexed selective filters that reduce the candidate set before sharing is applied.
• Skinny tables or custom indexes for hot queries.
• Read-optimized custom big object / analytics paths for very high cardinalities.

Common interview follow-ups

• Does with sharing affect @AuraEnabled methods? Yes — the keyword on the enclosing class applies.
• What’s WITH USER_MODE in modern Apex? A newer SOQL clause that enforces sharing, FLS, and CRUD in a single statement — the recommended modern approach to layered enforcement.
• What if the class has with sharing but the user has Modify All Data? That system permission bypasses record-level sharing — the class behaves as if it were without sharing for that user.

Verified against: Apex Developer Guide — Using the with sharing, without sharing, and inherited sharing Keywords. Last reviewed 2026-05-17.