Walked through 1,930 practice questions pulling from 24 source sets before sitting the Salesforce® Certified Platform Administrator exam. Thirteen of those questions had conflicting answers across sources — different prep decks gave different correct options for the same scenario.
That conflict list turned out to be the most useful study artifact. When two credible sources disagree, it usually means the distinction the exam is actually testing is subtle enough that a lot of candidates miss it. Below are five areas where we kept getting tripped.
1. Dashboard Running User is an access bypass most admins forget
Scenario type: a Case object is set to Private in OWD, but service reps can see cases they should not own when viewing a shared dashboard.
The instinct is to look at profiles, permission sets, or sharing rules. The actual cause is usually the dashboard's Running User setting. A dashboard configured to run as a System Administrator shows every record the admin can see — and then shares that view with anyone who has access to the dashboard. The viewer's own profile is irrelevant.
The fix is to set the running user to "Logged-in User" so each person sees only what their own access permits. This is a one-setting change in the dashboard's properties, but it is easy to miss during triage because the symptom looks like a profile or sharing problem.
2. Milestones track team dwell time; Escalation Rules track total age
Scenario type: leadership wants to know not just how long a case has been open, but how long it sat with each team specifically. The exam offers Escalation Rules, Flows, Case Assignment Rules, and Milestones — all with the Business Hours modifier.
Escalation Rules fire when a case has been open for a set duration without update. They measure total open time, not team-level handoff time.
Milestones with Business Hours is the correct tool here. Milestones are time-based targets attached to specific steps in an Entitlement process. Because they attach to the case at a point in its lifecycle — not to the total age — you can measure exactly how long the case sat at each queue or team before moving forward. They also carry native reporting fields (time to complete, violated flag) that Escalation Rules do not.
3. "Universally Required" and "Required on Record Type" are not the same
Scenario type: a field on a custom object must be populated on every record. The exam offers both "make the field universally required" and "require the field on the record type."
The difference matters in practice:
- Universally required makes the field required at the API level. Any record created programmatically — via data loader, integration, or Flow — must include the field or the operation fails. This is the right answer when the requirement says every record regardless of how it was created.
- Required on record type enforces the field only through the UI for that specific record type. API inserts and other record types are unaffected.
Most exam scenarios describe an end-user data entry requirement, which makes the record type option sound reasonable. But when the scenario specifically mentions an external billing system or integration, the universal requirement is correct because it enforces the constraint at the data layer.
4. Agentforce topic restrictions live in the agent instructions, not just FLS
Scenario type: an AI agent is deployed for employee HR questions. The requirement is that it should not respond to questions about a specific executive's private health benefits.
The trap is reaching for field-level security first. FLS prevents the agent from reading specific fields, but it does not prevent the agent from attempting to answer questions on a topic if it has access to other data that partially covers it.
The correct approach is to configure the agent's instructions and guardrails to explicitly block the topic. Guardrails are the dedicated mechanism for scoping what an Agentforce agent will and will not engage with, independent of what data it technically has access to. FLS handles what data the agent can retrieve; guardrails handle what topics it will discuss.
In practice you want both layers, but the exam question is asking which configuration specifically prevents the agent from responding on a topic — that is the guardrails layer.
5. Screen Flow conditional visibility sits on the component, not the screen
Scenario type: a Screen Flow collects Lead Source, and a second picklist should only appear when Lead Source equals "Search Engine." The exam offers conditional filters on the screen element versus visibility rules on the field component.
The distinction is where the logic lives:
- A conditional filter on the screen element controls whether the entire screen step is shown.
- Visibility rules on the field component (set in the Screen element's field configuration) control whether a specific field within the screen is shown or hidden.
For showing or hiding a single field based on another field's value on the same screen, the correct tool is the field component's visibility rules — not a conditional filter on the screen. Using a conditional filter would hide the entire screen when the condition is not met, which is not what the requirement describes.
What the conflict questions actually teach
The 13 questions where prep sources disagreed were not errors. They were cases where the answer genuinely depends on how you read the scenario — specifically which constraint the scenario emphasises.
For the exam, the pattern that resolved most conflicts: read what the requirement is trying to achieve at the data or process layer, not just the surface-level business description. The exam rewards candidates who distinguish between "this enforces at the UI" and "this enforces at the API," between "this limits what data is retrieved" and "this limits what topics are engaged."
If you are in admin prep now and want to compare notes on any of the five areas above, the contact page is the right place to start a conversation.
