Salesforce Admin common mistakes
Salesforce Admin · Understand the traps and how to avoid them.
When a scenario asks 'how do I let this user see or edit records owned by other people', the answer given is 'assign a permission set' or 'change the profile', and when the scenario asks for a field to be editable the answer given is 'move the role in the hierarchy'.
Profiles and permission sets and roles all look like 'permissions' in the setup menu, so candidates collapse them into one concept and answer with whichever they studied most recently.
What to do instead
Memorise the split and recite it before answering any access question: profiles and permission sets grant object permissions (create/read/edit/delete), field-level security, app and system settings - never record access. Roles and the role hierarchy, with organization-wide defaults, sharing rules, teams, territories and manual sharing, decide which records. OWD sets the baseline, the hierarchy opens it upward, sharing rules open it sideways. Record access never comes from a permission set alone unless it is a 'view all/modify all' permission.
Answering that a lookup relationship supports roll-up summary fields, or that a master-detail child record can have an owner different from its parent, or that deleting the parent leaves the child in place.
Candidates memorise 'master-detail is the stronger relationship' as a slogan without the specific mechanical consequences, so they guess on the details.
What to do instead
Drill the concrete master-detail behaviour list: roll-up summary fields are allowed, the child inherits the parent's owner, sharing is inherited from the parent, deleting the parent cascade-deletes the child, and the field is required on the child's page layout. Reparenting is only possible if 'Allow reparenting' is enabled. If any of those behaviours would break the requirement (child needs its own owner, must survive parent deletion, needs no roll-up), the correct answer is lookup. Junction objects between two master-detail relationships behave as master-detail on both sides.
Editing an object's page layout to add a field for Lightning Experience users, or building a Lightning record page and activating it as org default while assuming that covers every app and record type in the org.
Page layouts were the only layout tool for years, so 'make the field visible' maps straight to 'page layout' in memory, and activation options are easy to skim past.
What to do instead
In Lightning Experience the Lightning record page controls the overall layout; the page layout only supplies the fields available to the Fields component and still governs Salesforce Classic. Before building, check the page type (home, record, app, email) - a record page cannot be activated on home. Activation is per Lightning app, per record type, and optionally per profile, with a separate org default for the default app. If a field will not appear, check the Fields component, the page layout, field-level security and the record type assignment in that order.
Assuming that custom Lead fields automatically carry over to the Account, Contact and Opportunity at conversion, or that converting a lead deletes it.
Conversion feels like 'moving' a record, so candidates assume everything moves with it and the source disappears.
What to do instead
Learn the three outputs of conversion (Account, Contact, Opportunity - any of which can be suppressed, e.g. 'do not create a new opportunity') and that the Lead record remains, marked Converted and read-only; it is found through the Converted Leads list view. Custom lead fields map only if they have been added to the mapping in Lead settings, must be the same data type as the target field, and standard fields are pre-mapped and cannot be unmapped or remapped.
Mixing up case assignment rules with escalation rules, and treating queues as if they were public groups - for example answering 'create a public group with the support agents' to a question about routing new cases.
Queue, group, assignment rule and escalation rule all sound like 'where the case goes', and the exam tests the difference rather than the definition.
What to do instead
Fix the mental model: assignment rules decide the owner (user or queue) of new or edited cases and run in order of entry criteria; escalation rules act on age/time after creation and can reassign or notify; queues hold unowned records of one or more objects and are what Omni-Channel routes work from; public groups exist for sharing and are only relevant to routing if a queue's membership uses them. If the requirement mentions 'after 8 hours', it is escalation; if it mentions 'when created', it is assignment.
Answering 'add the field to the page layout' when the question asks why a field is missing from the mobile record card, the highlights panel, or a related-list preview.
Page layout is the default answer for anything about field visibility, and compact layouts are a small setup page most candidates never opened.
What to do instead
Separate the three: page layouts control the record detail and edit pages; compact layouts control the highlights panel, the Salesforce mobile record card and the related-list preview fields; Lightning record pages control the overall Lightning layout. If the scenario names mobile, highlights or related-list preview, the answer is compact layout (and remember FLS still applies on top of all of them).
Updating existing records by exporting and re-importing with a Data Loader Update matched on Name or another non-unique field, or loading child records in the same batch run as their parents - then accepting 'duplicate and unmatched rows' as an unavoidable cost.
Update feels like a simple overwrite, and the external ID + Upsert pattern is only in a corner of the Data Loader docs.
What to do instead
Use the pattern the exam rewards: create a text or number field marked as External ID on the object, populate it with your source key, and run Upsert so the key performs a match - never match on a non-unique field for updates. Load parents before children and verify the relationship field values reference the parent's external ID. Test with 10 rows, confirm the running user's field-level security and object permissions cover every mapped field, and remember the Import Wizard exists only for smaller volumes and a limited set of objects.
Answering a report question by adding a filter on a child field (or a filter set to 'not equal to') when the requirement is 'accounts with no open opportunities' or 'contacts without cases', or picking a report type that has no relationship between the objects.
Filters are the first tool candidates reach for, and 'not equal to' reads like 'does not have' even though it excludes only rows that exist and fail the test - blank and missing child rows behave differently.
What to do instead
Map the phrasing to the tool: 'with / without' related records means a cross filter (only available when the chosen report type traverses that relationship); 'group by' means a summary or matrix format; 'range or tier' means a bucket field; 'compare groups' means a summary formula. Say the report type out loud first - if it doesn't include both objects, no filter or cross filter can save the answer.
Translating 'if Billing State is blank OR Billing Postal Code is blank, show an error' into AND(ISBLANK(BillingState), ISBLANK(BillingPostalCode)), or testing for blanks with BillingState != null.
In everyday language 'if either field is blank' sounds like a joint condition, and 'not equal to null' is the habit carried over from SQL, so the logic is inverted or never fires.
What to do instead
Transcribe literally, function by function: everyday 'and' becomes AND(), everyday 'or' becomes OR(), and each blank test becomes ISBLANK(field) (ISBLANK handles text, number and date). 'A or B is blank' is OR(ISBLANK(A), ISBLANK(B)); 'both A and B are blank' is AND(...). Before saving, write one record that should pass and one that should fail and check the rule fires on the second, remembering validation rules also fire on imports and API calls.
Choosing Process Builder or a workflow rule for a new automation, or building an after-save record-triggered flow whose only job is to update fields on the same record, and leaving entry conditions out of the flow.
Older study material and muscle memory point to Process Builder and workflow rules, and before-save versus after-save looks like an implementation detail rather than the thing the question is testing.
What to do instead
Default to Flow for all new build requirements. Use a before-save record-triggered flow when the automation only changes fields on the triggering record - it is faster and needs no extra DML. Use after-save when you must create or update related records, post to Chatter, send email or call an Apex action. Use a scheduled path for time-based steps such as 'create a task 3 days later'. Use an approval process only when a human decision gate is required. Always define entry conditions so the flow runs only on the intended records, and check recursion if the flow updates records that re-trigger it.