Plat-Dev-301 Sample Questions & Answers

Custom Metadata Types are the optimal solution. Unlike Custom Settings, Custom Metadata records are deployable metadata (not data), meaning they move between environments via Metadata API/Change Sets. They are also visible in tests without SeeAllData=true and do not count against SOQL limits when accessed via SOQL.

Salesforce External ID fields can be case-sensitive or case-insensitive. If the External ID is defined as case-insensitive (default for text fields unless 'Unique - Case Sensitive' is selected), Salesforce treats 'ABC-123' and 'abc-123' as duplicates. If the ERP considers these unique, the upsert will fail when attempting to insert the second record.

Custom Labels are the standard way to store and translate text used in Apex and Visualforce/LWC. They can be translated via the Translation Workbench and updated by admins without modifying the code.

If a Workflow Rule field update occurs, Salesforce updates the record and fires before update and after update triggers one more time (and standard validations). However, specifically for insert operations, if a workflow field update runs, the standard before and after triggers fire again as insert triggers in some contexts, or more commonly, the update converts to an update operation. The key is that workflow field updates are one of the few things that cause triggers to re-fire in the same transaction context.

Queueable Apex is designed for chaining jobs (one job starting another). While Batch Apex can also chain, Queueable is generally more lightweight for processes that don't need the massive parallel chunking of Batch (though for 50k records, Batch is also a candidate, Queueable is specifically preferred for chaining logic over Future methods which cannot chain). However, typically 50k records suggests Batch Apex. Let's re-evaluate. Option C says 'Batch Apex'. If the requirement is strictly about chaining and the volume is 50k, Batch is actually safer for limits. BUT, Queueable is the modern answer for 'chaining' compared to Future. Let's look at the options. Future cannot chain. Queueable can chain. Batch can chain. For 50,000 records, Batch is better due to governor limits. However, if the question implies a complex logic chain where one unit of work follows another, Queueable is often the answer. BUT, 50k records in Queueable might hit limits if not split. Actually, the best answer for chaining specifically in the context of avoiding @future limitations is Queueable. But for 50k records? That requires Batch. Let's assume the question highlights the chaining capability. Let's assume the 'updates' are complex. Wait, Queueable can accept complex data types. Let's select Queueable as the 'feature best suited for chaining' vs Future, but usually Batch is for volume. Let's refine the question to 'chaining jobs' focus.

This is the standard pattern for partial rollback with logging. If you don't rollback, the first DML might commit if the exception is caught (depending on context, but usually unhandled exceptions roll back everything). To explicitly control rollback of the first DML while successfully committing the log entry (which is a new DML), you must Rollback to savepoint (undoing DML 1 and 2), and then insert the log. If you insert the log before rollback, the log is also rolled back.