Salesforce Advanced Admin common mistakes
Salesforce Advanced Admin · Understand the traps and how to avoid them.
Granting 'View All Data' or 'Modify All Data' on a permission set to satisfy a requirement that a support team see every case of a given record type.
Candidates reach for administrator superpowers as if they were a sharing design, because those permissions do make records visible immediately in a sandbox test.
What to do instead
Fix the design instead: record types plus org-wide defaults, criteria-based sharing rules, or queues/territory hierarchy. Reserve View All Data and Modify All Data for genuine admin access and say so explicitly in the rationale.
Answering that field-level security set to hidden on a user's profile keeps the field hidden even though a permission set assigned to that user grants read or edit on it.
A profile-shaped mental model treats the profile as a higher tier that overrides everything else, when Salesforce access is additive.
What to do instead
Apply the most-permissive-wins rule: effective FLS is the union of profile and all permission sets. To restrict a field, it must be removed from every profile and permission set the user holds.
Choosing a master-detail relationship because it 'supports roll-ups', without checking whether the child records must exist independently or need their own sharing.
Master-detail is taught as the default 'stronger' relationship, so candidates stop analysing the requirement before picking.
What to do instead
Test the requirement against inheritance: detail records inherit the parent's sharing, cannot exist without a parent, and are cascade-deleted. If any of those break the requirement, choose lookup and solve aggregation another way.
Proposing a roll-up summary field to aggregate child records across a lookup relationship.
Roll-up summaries and master-detail are memorised together as 'the aggregate feature', and the relationship pre-condition gets dropped under time pressure.
What to do instead
State the pre-condition first: roll-up summary fields require a master-detail relationship (or a relationship to a standard object that behaves as master-detail). Otherwise propose a record-triggered flow or Apex, or convert the relationship and accept the trade-offs.
Selecting Setup Audit Trail when the question asks which user caused an Apex exception, a login failure, or a change to a record's field value.
All three feel like 'auditing', and Setup Audit Trail is the best-known audit feature, so it becomes the default answer.
What to do instead
Map each question to the right lens: Setup Audit Trail = configuration/metadata changes, last 180 days; field history tracking or Field Audit Trail = record field changes; debug logs, Apex exception email, or Event Monitoring = runtime errors and user activity.
Telling the requester that deleted records stop consuming storage the moment the delete completes, and leaving the Recycle Bin out of a data-load or storage plan entirely.
Delete is assumed to be immediate and final, and the Recycle Bin is treated as a UI convenience rather than a storage and data-volume factor.
What to do instead
Account for the Recycle Bin as storage-consuming until it is emptied, and note that purging it (or using hard delete with the permission granted) is a separate, irreversible step that belongs in the runbook.
Designing an upsert that matches on a plain text or number field that has not been marked as an External ID.
The intent of 'update if it exists, insert if not' is clear, so candidates assume any field with unique values can serve as the match key.
What to do instead
Upsert matches only on a field flagged External ID (and must be unique for reliable results). State that the field has to be created or edited with External ID and, where relevant, the unique and case-sensitive settings before the load.
Answering that validation rules fire before a before-save record-triggered flow touches the record, or that the flow and the workflow field update run in an order the candidate never checks.
Order of execution is memorised as a list of feature names rather than as a sequence, and before-save flows are new enough that they get slotted in by intuition.
What to do instead
Recite the sequence in the order it matters for the question: before-save flow, then system validation, then before triggers, then custom validation rules, then save, then after triggers, assignment rules, workflow rules, and after-save flows. Use it to answer 'will this record save?' questions.
Assuming a change set gives you a rollback if the deployment goes wrong, or that a change set can remove a component from the target org.
Deployment is conflated with version control, where reverting is a normal expectation, and destructive changes are assumed to travel with the rest of the metadata.
What to do instead
Plan for no native rollback: rehearse in a full sandbox, retrieve a backup of the target metadata first, and remove components with a destructive changes manifest via the Metadata API (SFDX/Ant), not a change set.
Selecting case escalation rules, or a workflow rule, as the mechanism that routes newly created cases to the correct queue.
Escalation and assignment both sound like 'moving cases around', and the time-based nature of escalation is easy to overlook under exam pressure.
What to do instead
Separate the two jobs: assignment rules (with case queues as the assignee) route cases at creation or on manual assign; escalation rules are time-based and only act on cases already owned by a queue or user who is a member of the escalation rule.