Free ADM-201 flashcards

Why would you mark a custom field as an External ID before running an upsert in Data Loader?

An External ID indexes a unique value from a source system, and upsert uses that value as its match key to decide whether to create a new record or update an existing one, without needing the Salesforce record ID.

Validation rules only fire when a user edits a record manually through a Lightning record page, not during any automated process.

It is tempting to think validation only guards manual edits, but rules also fire on API and automation-driven saves, so limiting them to manual edits is wrong.

With an org-wide default of Public Read Only, how do you let one group edit every record of an object without loosening the baseline for anyone else?

Create an owner-based sharing rule keyed on records owned by all internal users and share them with that group at Read/Write. Sharing rules only ever open access wider than the org-wide default, so the group gains edit rights while the Public Read Only baseline stays intact for everyone else.

To let the compliance team edit all Contract records, change the Contract org-wide default to Public Read/Write.

Tempting because it guarantees the compliance team can edit, but it grants edit access to the entire organisation, which contradicts the requirement to change nothing else about the baseline.

When you delete a parent record, how does the outcome differ between a master-detail relationship and a lookup relationship?

Master-detail is tightly coupled, so a detail record cannot exist without its master and deleting the parent cascades the delete to its children. A lookup is loosely coupled and leaves the child records untouched when the parent is removed.

When a parent is deleted, the child records are automatically deleted in both master-detail and lookup relationships.

It is tempting because both relationships link a child to a parent, but only master-detail cascades the delete. A lookup does not delete its child records by default.

In a record-triggered flow, which run timing should update a field on the same record that triggered it, and why?

Before-save timing. The flow runs while the record is still in the current transaction and not yet committed, so setting a field on that record needs no extra DML and is markedly faster than an after-save update, which re-saves the record.

Use after-save for a same-record update because only after-save flows can read the triggering record's field values.

Tempting because after-save flows are common, but wrong: both before-save and after-save flows can read the triggering record's field values, so this is not a reason to prefer after-save.