THE IDEA TO KEEP

A permission decision should be easy to spot in a code review.

Three questions before a query

Can this user see the record? Can they read the object? Can they read the fields? Treat these as separate review questions.

with sharing controls record sharing; that declaration alone does not enforce object or field permissions. Explicit WITH USER_MODE makes the query's access policy clear. Salesforce's current security guide also distinguishes defaults before and after API 67.0. Check your class API version instead of relying on a remembered default.

Put the policy next to the data

This original controller offers a bounded list of accounts to a Lightning component. The sharing declaration and query access mode are both visible. Sorting by name and ID gives equal names a stable tie-breaker.

AccountDirectory.clsAPEX
public with sharing class AccountDirectory {
    @AuraEnabled(cacheable=true)
    public static List<Account> listAccounts() {
        return [
            SELECT Id, Name, Industry
            FROM Account
            WITH USER_MODE
            ORDER BY Name, Id
            LIMIT 50
        ];
    }
}

Class access must also be granted through a profile or permission set.

Design the permission failure

User-mode queries can fail when requested objects or fields are inaccessible. Give the UI a useful error state. When intentionally supporting partial field access, investigate Security.stripInaccessible() and consume its sanitized records; it does not replace record-sharing decisions.

For this directory, try a user who can read Account but not Industry. Should the entire directory be unavailable, or should Industry be optional? Resolve that product decision before selecting the implementation. Add a test for the chosen outcome, plus a user who cannot see one of the fixture records.

Go a little deeper.

Official references behind this note:

Examples are for learning. Validate them in a practice org against your API version, permissions, validation rules, and existing automation.