Secure the Application

A Sales rep should see Project__c.Health__c but has no legitimate need to see Time_Entry__c (internal Delivery hours logged against a project) or the details of every Support_Case__c. A Support agent needs to see Support_Case__c and enough Project__c context to do their job, but not necessarily Time_Entry__c either. This is a genuinely more nuanced access picture than Module 42\'s banking system, where essentially every field mattered to the account owner uniformly.

public with sharing class TimeEntrySelector {
    public List<Time_Entry__c> selectByProjectId(Id projectId) {
        return [
            SELECT Id, Hours__c, Logged_By__c
            FROM Time_Entry__c
            WHERE Project__c = :projectId
            WITH SECURITY_ENFORCED
        ];
    }
}

Because every query in this project already flows through Module 43\'s selector layer, with sharing and WITH SECURITY_ENFORCED enforcement is automatic and consistent everywhere — a Support agent without field-level access to Time_Entry__c simply cannot retrieve that data through TimeEntrySelector, regardless of which service or trigger handler happens to call it.

If security had instead been enforced ad hoc, scattered across many individual queries the way Module 43\'s Lesson 4 originally warned about, verifying "does every query respect field-level security?" would require auditing every call site individually. Because this project centralized all queries into selectors from the start (Lessons 4 and 7), that audit is instead: "does every selector apply WITH SECURITY_ENFORCED?" — a small, easily verified checklist.