Free Plat-Dev-301 sample questions

Correct answer: SOQL Aggregate queries do not support automatic currency conversion when Advanced Currency Management is enabled; the `convertCurrency()` function cannot be used with aggregate functions.

This is a specific limitation of SOQL. When Advanced Currency Management (dated exchange rates) is enabled, you cannot use the `convertCurrency()` function in the SELECT clause if you are also using aggregate functions (like SUM or MAX) or GROUP BY clauses. The conversion logic must be handled in Apex post-query or via a different architectural approach.

Correct answer: True

True: In Apex, you cannot access the compound field `Delivery_Location__c` directly as a single object. You must access its constituent fields, `Delivery_Location__Latitude__s` and `Delivery_Location__Longitude__s`, individually to perform calculations or logic. However, in SOQL, you can select the compound field directly.

Correct answer: Custom Metadata Types

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.

Correct answer: The `ERP_Key__c` field is not case-sensitive, and the ERP system treats keys differing only by case as unique.

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.

Correct answer: Use Custom Labels and reference them in Apex using `System.Label.LabelName`. Translations are managed in the Translation Workbench.

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.

Correct answer: The Workflow Rule field update caused the record to undergo the save procedure again, firing `before` and `after` triggers a second time.

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. flowchart TD Start([Start Save]) --> Load[Load Original Record] Load --> BeforeTrig[Before Triggers] BeforeTrig --> Val[System Validation] Val --> AfterTrig[After Triggers] AfterTrig --> Assign[Assignment Rules] Assign --> AutoResp[Auto-Response Rules] AutoResp --> WF[Workflow Rules] WF -- Field Update? --> Update{Yes} Update --> ReFire[**Fire Triggers Again**] Update --> Commit([Commit]) WF -- No Update --> Commit