Enforce Field-Level Security

A trigger runs in the context of the user who performed the DML — if a user without access to the Type field somehow creates a Case (through an integration or a UI that doesn't enforce FLS on that specific field), a naive trigger reading Trigger.new[0].Type could behave unpredictably. Checking field accessibility explicitly, even inside trigger logic, is Module 28's habit carried through consistently.

public class CaseTriggerHandler {
    public void beforeInsert(List<Case> newCases) {
        Boolean canReadPriority = Schema.sObjectType.Case.fields.Priority.isAccessible();
        Boolean canReadType = Schema.sObjectType.Case.fields.Type.isAccessible();

        if (! canReadPriority || ! canReadType) {
            System.debug('Skipping auto-routing: missing field-level access to Priority or Type.');
            return;
        }

        // ... routing logic uses newCases (next lessons) ...
    }
}

This is exactly Module 28's Schema.sObjectType.Object.fields.Field.isAccessible() pattern — checked once, before any per-record routing logic runs, rather than assumed to always be safe.

Notice this returns early rather than calling addError() (Module 26) to block the save. Missing field access to Priority/Type means auto-routing simply can\'t happen correctly — but that's not a reason to prevent the Case itself from being created. This is a deliberate choice worth naming: not every security check should escalate to a hard block; sometimes gracefully skipping optional automation is the more appropriate response.