Salesforce PD1 - Platform Developer I - Apex SOQL LWC Triggers Testing Deployment

Salesforce's deployment requirements for Production: (1) At least 75% code coverage across ALL Apex code in the org (the aggregate across all classes and triggers combined must be ≥75%); (2) All Apex tests must pass (no failing test methods); (3) Every trigger must have at least some code coverage (though the 75% threshold is the org-wide aggregate). The coverage is measured at the org level, not just for the code being deployed — adding poorly covered code to an org that's barely above 75% can cause a deployment failure. Option A (all trigger tests passing) is a partial answer. Option C (100% on deployed code) is more than required — 75% is the threshold. Option D is incorrect — both triggers AND classes require coverage.

The Salesforce CLI sf deploy metadata command with --check-only flag performs a "check-only" (validation) deployment that: runs all deployment validations (metadata format, dependencies), compiles Apex code, runs specified test classes without committing changes to the org. --test-level RunSpecifiedTests with --tests MyTriggerTest specifies which tests to run during validation. This is the pre-deployment validation step that confirms the deployment will succeed before making live changes. Option B (--dry-run) is not a valid Salesforce CLI flag. Option C (sf test run) executes tests in the target org but doesn't validate a deployment package. Option D (--validate) is a partial command — check-only is the correct flag and --validate is not a standalone Salesforce CLI flag.

Salesforce enforces a key rule: you cannot make a callout from a trigger context AFTER DML has been performed in the same transaction (you'll get "You have uncommitted work pending" error). The correct pattern is to: use a @future(callout=true) method or Queueable Apex (which also supports callouts) called from the trigger. The trigger collects necessary data (record IDs, field values), passes them to the @future/@queueable method, the trigger transaction commits, and the async method executes the callout in a separate transaction context. Option A (direct callout in trigger) fails with an exception if DML occurred before the callout in the same transaction. Option C (Scheduled Apex) adds unnecessary delay and doesn't handle individual record callouts contextually. Option D (Platform Event + Flow) could work but is more complex than @future for this pattern.

Messaging.SingleEmailMessage with setTemplateId() enables dynamic template selection in Apex: (1) Query the EmailTemplate table by API name or folder: EmailTemplate template = [SELECT Id FROM EmailTemplate WHERE Name = 'Technical Case Template']; (2) Create Messaging.SingleEmailMessage msg = new Messaging.SingleEmailMessage(); msg.setTemplateId(template.Id); msg.setTargetObjectId(caseContactId); msg.setWhatId(caseId) (for merge fields from Case); (3) Messaging.sendEmail(new List<Messaging.Email>{msg}). The logic to select Technical vs. Billing template is handled by Apex conditional logic (if/else or switch statement). Option A (System.debug) does nothing functionally. Option C and D (Process Builder/Workflow) are declarative tools that work but lack the flexibility of Apex code for complex template selection logic.

System.isRunningTest() returns true when the current code is executing within a test context (@isTest annotated method). This is useful for: conditional logic that should behave differently in tests (e.g., skip external callouts), mock responses in test context, or preventing side effects during test execution. For example: if (!System.isRunningTest()) { /* make real callout */ } else { /* return mock data */ }. Note: using Test.isRunning() (Option C) is the same concept but the correct method name is System.isRunningTest(). Options A and D don't exist in Apex. Note: while Test.isRunning() is sometimes referenced colloquially, the official method is System.isRunningTest().