Secure Account Data

public with sharing class BankAccountService {
    public static List<Bank_Account__c> getAccountsFor(Id userId) {
        return [
            SELECT Id, Balance__c, Status__c
            FROM Bank_Account__c
            WHERE OwnerId = :userId
            WITH USER_MODE
        ];
    }
}

1. public with sharing class BankAccountService { — with sharing, not left to the default.
2. public static List<Bank_Account__c> getAccountsFor(Id userId) { — the method signature.
3. return [ — opens the query.
4. SELECT Id, Balance__c, Status__c — includes the sensitive Balance__c field.
5. FROM Bank_Account__c — the object.
6. WHERE OwnerId = :userId — scoped to a specific user's own accounts.
7. WITH USER_MODE — Module 28's field- and object-level enforcement, applied automatically.
8. ]; — closes the query.
9. } — closes the method.
10. } — closes the class.

with sharing and WITH USER_MODE are Module 28's exact security mechanisms — for a banking system, enforcing that a user can only see accounts and balances they're actually permitted to see isn't optional polish, it's the whole point of the security lesson finally mattering in a domain where the stakes are obvious.

trigger TransactionValidation on Transaction__c (before insert) {
    Set<Id> accountIds = new Set<Id>();
    for (Transaction__c t : Trigger.new) accountIds.add(t.Bank_Account__c);

    Map<Id, Bank_Account__c> accounts = new Map<Id, Bank_Account__c>(
        [SELECT Id, Balance__c, Status__c FROM Bank_Account__c WHERE Id IN :accountIds]
    );

    for (Transaction__c t : Trigger.new) {
        Bank_Account__c acc = accounts.get(t.Bank_Account__c);
        if (acc.Status__c != 'Active') {
            t.addError('This account is not active and cannot accept transactions.');
        } else if (t.Type__c == 'Withdrawal' && t.Amount__c > acc.Balance__c) {
            t.addError('Insufficient funds for this withdrawal.');
        }
    }
}

1. trigger TransactionValidation on Transaction__c (before insert) { — a separate trigger, deliberately kept apart from Lesson 2's after insert one.
2. Set<Id> accountIds = new Set<Id>(); — collects the distinct account Ids involved.
3. for (Transaction__c t : Trigger.new) accountIds.add(t.Bank_Account__c); — one loop, no query yet.
4. (blank line)
5. Map<Id, Bank_Account__c> accounts = new Map<Id, Bank_Account__c>( — a Map constructed directly from a query's results.
6. [SELECT Id, Balance__c, Status__c FROM Bank_Account__c WHERE Id IN :accountIds] — exactly one query, for every involved account at once.
7. ); — closes the map constructor.
8. (blank line)
9. for (Transaction__c t : Trigger.new) { — a second loop, now with the accounts already in hand.
10. Bank_Account__c acc = accounts.get(t.Bank_Account__c); — looks up this transaction's account from the map — no additional query.
11. if (acc.Status__c != 'Active') { — the status check.
12. t.addError('This account is not active and cannot accept transactions.'); — blocks the record entirely.
13. } else if (t.Type__c == 'Withdrawal' && t.Amount__c > acc.Balance__c) { — the overdraft check.
14. t.addError('Insufficient funds for this withdrawal.'); — blocks the record entirely.
15. } — closes the if/else if.
16. } — closes the for loop.
17. } — closes the trigger.

This is a separate before insert trigger, deliberately kept apart from Lesson 2's balance-update after insert trigger — Module 24's separation-of-concerns principle, applied here so that validation logic and balance-update logic can each be tested (Lesson 7) and reasoned about independently.

before insert runs, and can call addError() to block the record entirely, before Lesson 2's after insert balance-update trigger ever executes. This ordering guarantee means an invalid overdraft transaction never reaches the balance-update logic at all — it's rejected outright, exactly the fail-safe design a banking system requires.