Free Salesforce-Platform-Administrator Practice Test Questions (2026)

Explanation:
Action instructions in Salesforce (e.g., for Einstein Bots or Flows) should be clear, user-intent focused, and action-oriented. Best practices emphasize describing what the action does, why it is used, and when an agent should invoke it, avoiding technical jargon or overly simplistic statements.

Correct Option: B

Clear purpose: States the action creates a Salesforce Case record.

Goal-oriented: Explains the goal is to document a customer’s issue.

Trigger condition: Specifies “when the user’s intent is to create a formal record of their problem or question,” guiding proper usage.

Professional tone: Concise yet complete for an agent’s understanding without technical overload.

Incorrect Option: A

Too simplistic and vague (“simply save customer information”).

Lacks a clear trigger condition or intent-based guidance.

Does not emphasize documenting a “problem” or “issue,” which is central to Case creation in Salesforce.

More suitable for a generic save operation, not a Case-specific action.

Incorrect Option: C

Overly broad (“any type of customer inquiry”).

Misses the key nuance that Cases represent issues/problems, not all inquiries.

Does not guide the agent on when to use it beyond saving an interaction record.

Lacks the intent-based clause present in the correct answer.

Incorrect Option: D

Contains technical jargon (“code snippet,” “runs in the background”).

Incorrectly states purpose as “solve the customer’s issue” (Case creation logs the issue; resolution comes later).

Focuses on behind-the-scenes mechanics rather than agent decision-making.

Violates best practices for user-friendly action instructions.

Reference:
Salesforce Trailhead: Build Actions for Einstein Bots – Best practices for action instructions recommend using clear, intent-driven language that describes what the action does, its goal, and when to use it. Avoid technical implementation details.

Explanation:
Prompt templates in Salesforce (e.g., for Einstein GPT or Prompt Builder) need to pull live record data to generate contextual responses. Merge fields act as placeholders that dynamically replace with actual field values from a Salesforce record (like Case ID, Subject, or Description) when the prompt executes.

Correct Option: D

Merge fields (e.g., {!Case.Subject} or {!Case.Description}) dynamically insert real Salesforce data into prompts.

They are evaluated at runtime, pulling the current record's field values.

No coding required; administrators can use them directly within prompt templates.

Essential for personalizing summaries with customer-specific case details.

Incorrect Option: A

Flows are automation tools for logic, data manipulation, and screen flows, not for inserting dynamic data into text-based prompt templates.

While a flow can call a prompt, the prompt template itself uses merge fields, not flows, to display record data.

Overkill and incorrectly scoped for simple data insertion in a template.

Incorrect Option: B

Picklists are field types that provide a predefined set of values for data entry (e.g., Case Priority: High/Medium/Low).

They do not dynamically display real-time Salesforce data within a prompt template.

Picklists store static values; they cannot act as placeholders for record-specific data at runtime.

Incorrect Option: C

Agent Instructions are guidance text for human agents (e.g., in Omni-Channel or Einstein Bot actions) on how to handle a conversation.

They do not dynamically populate data from Salesforce records into a prompt response.

Agent Instructions are static or intent-based, not merge-capable placeholders.

Reference:

Salesforce Help Article: Create Prompt Templates with Merge Fields – Merge fields in Prompt Builder allow you to personalize prompts by inserting field values from Salesforce records. Use {!Object.FieldName} syntax to dynamically pull data at runtime.

Explanation:

In Salesforce, every username must be unique across all Salesforce orgs globally (production, sandbox, Developer Edition, trial orgs, etc.) — not just within your own org. This is a fundamental platform requirement because the username (combined with password) serves as the login credential, and the login page (login.salesforce.com or test.salesforce.com) must be able to uniquely identify which org a user belongs to.

So, if another user in any other Salesforce org (anywhere in the world) is already using the same username string, Salesforce will reject the new user record with a duplicate username error.

Why the other options are wrong

A – The username was not configured in the format of an email address
While usernames must be formatted like an email address (e.g., [user@domain.com](mailto:user@domain.com)), a formatting error would produce a validation error saying the username is not in the correct format, not a "duplicate username" error.

B – The email address and username must be unique across all Salesforce orgs
This is incorrect. The email address does not need to be globally unique — only the username must be globally unique. Multiple users can have the same email address across different orgs (and in some cases even within the same org), though it's not best practice for password resets.

D – The username has a restricted domain name within it
There's no concept of a globally "restricted domain name" for usernames that applies here. Certain domains might be restricted for email deliverability or specific org settings, but that would not cause a duplicate username error.

Reference
Salesforce Help: Username Uniqueness
Salesforce recommends using email addresses as usernames specifically because they tend to be unique and help avoid this exact global duplication issue.

Explanation:
When Agentforce (Einstein Bot or conversational AI) escalates a case to a human support agent, critical context like the chat transcript, bot interaction history, and customer responses must be visible on the case record. Without this, agents have no visibility into prior conversation, forcing customers to repeat information.

Correct Option: B

The agent history component (often called "Conversation History" or "Chat Transcript" related list) displays the full bot-customer interaction on the case page layout.

If missing from the support team's case page layout, agents cannot see previous messages, intents, or data collected.

This directly causes the "no context" complaint because the information exists on the case record but is not displayed.

Adding this component to the page layout resolves the issue without changing automation logic.

Incorrect Option: A

The Agentforce User permission set grants access to use Agentforce features (e.g., running bots, viewing analytics).

Missing this permission would prevent agents from accessing Agentforce entirely, not just losing context after escalation.

Agents can still receive escalated cases without this permission set; context loss is a visibility issue, not a permission issue.

Incorrect Option: C

Agent instructions guide bot behavior during conversation (e.g., what questions to ask).

They do not prevent history from being saved to the case record. History is saved based on configuration of the handoff or case creation step.

Instructions control bot logic, not data persistence or page layout visibility.

Incorrect Option: D

Creating a new case instead of transferring a session would lose context, but the question states cases are being escalated to the support team.

If a new case were created each time, prior conversation data would not be associated at all. However, the issue is agents "have to ask the customer to repeat everything," suggesting data exists but is not visible.

Missing page layout component (Option B) is far more common and likely than a misconfigured handoff creating new cases.

Reference:
Salesforce Help Article: Add the Chat Transcript Component to Case Page Layouts – To provide agents with full conversation history from Einstein Bots or Agentforce, the Chat Transcript or Conversation History related list must be added to the case page layout. Without it, agents see no prior context after escalation.

Explanation:

To give users access to Service Cloud features — especially the Service Console for managing cases — the key requirement is the Service Cloud User feature license (sometimes referred to as the Service Cloud User permission).

This feature license must be enabled on the individual User Detail page (or via bulk user edit). It unlocks Service-specific functionality, including full access to the Service Console, case management tools, and related Service Cloud objects/permissions that are not available with a basic Salesforce or Sales Cloud-only license.

The scenario states that the Platform Administrator will assign the new support reps to existing custom support profiles. Since the profiles are already in place (and presumably have the console app assigned and necessary object permissions), the missing piece for console access is typically the Service Cloud User feature license.

Why the other options are incorrect

B. Create a permission set for the Service Console and assign it to the support reps
Permission sets are excellent for granting granular permissions (e.g., specific object permissions, app visibility, or Lightning Console User). However, many core Service Console capabilities still require the underlying Service Cloud User feature license first. A permission set alone is usually not sufficient if the feature license is missing.

C. Build a Service Console using Lightning App Builder for the custom service profile
This is unnecessary and incorrect. The standard Service Console (Lightning Console app) already exists and is provided by Salesforce. Admins do not normally rebuild it from scratch in App Builder for this purpose. You configure and assign existing console apps via App Manager or profiles/permission sets.

D. Assign the Salesforce Platform User License to the support reps
The Salesforce Platform license is a limited license. It does not include access to standard CRM objects like Cases or the full Service Console. It is meant for custom apps and is too restrictive for support reps who need to manage cases.

Reference:
Configuration and Setup
Sales and Service Cloud Applications
User Setup and Licenses

Explanation:

Why Setup Audit Trail is correct

The Setup Audit Trail in Salesforce is specifically designed to track configuration changes made by administrators.

It records things like:

Who made the change
What change was made
When it was made

It is used for admin-level tracking of setup and configuration changes, especially when multiple system admins are working in the same org.

You can view:

Last 6 months of setup changes in the UI
Up to 180 days via the downloadable audit file

Why the other options are incorrect

Health Check
Used to evaluate security settings against Salesforce best practices. It does not track configuration changes.

History Tracking
Refers to field history tracking on records. Tracks changes to data (like Account name or Case status), not setup changes.

Feed Tracking
Used for Chatter feeds. Shows updates on record fields inside feeds, not admin configuration changes.

Key ADM-201 takeaway
Setup Audit Trail = tracks admin configuration changes in Setup
If it’s about who changed what in Setup, this is almost always the correct tool.

Explanation:
An Employee Agent (e.g., an Einstein Bot or conversational AI) can only access and respond with data that the underlying user (often a named "Integration User" or the running user) has permission to see. The most secure and reliable way to prevent responses about restricted data is to ensure the agent's user context cannot access that data at the database level.

Correct Option: B

Field-level security (FLS) and object permissions control what data the agent's running user can read.

If the CEO's health plan details are stored on a custom object or field, restrict those fields from the agent's user profile or permission set.

The agent cannot respond to what it cannot query—this is a fundamental Salesforce security principle.

More reliable than instructions or training, as it enforces actual data access restrictions.

Incorrect Option: A

Assignment rules determine which user or queue receives a record (e.g., case assignment), not what data an agent can read or respond to.

They do not control data visibility or prevent an agent from answering a question.

Irrelevant to restricting responses about a specific person's health plan.

Incorrect Option: C

Agent instructions and guardrails are conversational rules that tell the agent not to answer certain questions (e.g., "Do not respond to CEO health queries").

However, a determined or poorly phrased question might bypass guardrails (e.g., "Tell me about John Doe's medical coverage").

Instructions are a soft control, not a hard security boundary like FLS.

Incorrect Option: D

Training the agent on a different dataset (e.g., only general employee plans) is not a native Salesforce configuration.

Even if trained, the agent might still access the CEO's data via retrieval-augmented generation (RAG) or search if permissions allow it.

Training alone does not prevent data access; permissions do.

eference:
Salesforce Help Article: How Einstein Bots Respect Object and Field Permissions – Einstein Bot responses honor the running user's field-level security and object permissions. If the running user cannot see a field, the bot cannot read or respond with that data. This is the recommended method for restricting sensitive data from bots.

Explanation:

Universal Containers wants collaborative selling with repeatable, consistent team membership on Accounts. The key requirement is:

Automatically add the same team members (Sales Engineer, Support Rep, etc.) to multiple accounts.
Define specific access levels for each role on the Account (and optionally on related Opportunities and Cases).

This is exactly what Default Account Teams are designed for.

How Default Account Teams Work

An administrator or user can define Default Account Teams on their User record.
These default teams can include multiple roles (e.g., Sales Engineer, Support Rep, etc.).
You can specify different access levels for each team member:

Read Only
Read/Write

When a new Account is created by that user (or manually added), Salesforce can automatically add the Default Account Team members to the Account Team on that record.

Account Teams can also grant access to related Opportunities and Cases associated with the Account.

This perfectly matches the requirement of “automatically adding the same team members to multiple accounts” while controlling access levels.

Why the other options are not the best fit

B. Create sharing rules to grant access to opportunities and cases for support teams
Sharing rules are good for granting record-level access based on ownership or criteria, but they do not automatically add users as Account Team members, nor do they easily allow the same consistent team to be added across many accounts. They are more manual and ownership-based.

C. Configure role hierarchy to automatically grant account access to the appropriate teams
Role hierarchy grants access based on the organization chart (managers above get access to subordinates’ records). It does not support adding specific cross-functional team members (Support Reps and Sales Engineers) to accounts with custom access levels. Role hierarchy is too rigid for this collaborative selling use case.

D. Use permission sets to provide additional access to account-related records
Permission sets control object-level permissions (CRUD, View All, Modify All) and app visibility, but they do not grant record-level access to specific Accounts, Opportunities, or Cases. They cannot automatically add team members to accounts.

Key Tip for the Exam
Account Teams → Used for collaborative selling on Accounts
Opportunity Teams → Used for collaborative selling on Opportunities
Default Teams make the process automatic and repeatable.

Explanation:

Salesforce allows administrators to define Trusted IP Ranges at the profile or organization level. When a user logs in from a computer within these ranges, Salesforce recognizes the IP as trusted and does not require additional identity verification (such as email confirmation or security token).

In this scenario, call center reps move between desks but remain within the company’s network. By configuring the company’s network IP addresses as Trusted IP Ranges, the reps can log in seamlessly without repeated authentication prompts, regardless of which desk they use.

Why not the other options?

Custom Profile
Profiles control permissions, not login authentication behavior.

Multi-factor Authentication (MFA)
Adds extra security steps, which is the opposite of streamlining login.

Permission Set
Grants additional permissions but does not affect login authentication.

Reference
Salesforce Help: Login IP Ranges
Trailhead Module: Identity Basics → Covers trusted IP ranges and login flows.

Explanation:

In Salesforce, certain dependencies act as "blockers" that prevent a user from being deactivated.

The Running User Blocker
A dashboard is configured to display data as if a specific person is viewing it (the "Running User"). If that user is deactivated, the dashboard would break because it can no longer access the data through that user's security lens. You must change the running user of the dashboard before Salesforce will allow you to deactivate the account.

Other Common Blockers
You also cannot deactivate a user if they are the sole recipient of a workflow email alert or the selected user in a custom hierarchy field.

Why other options are incorrect

B (Case Assignment Rule)
Salesforce allows you to deactivate a user who is part of an assignment rule. However, it is a "best practice" to remove them first, as future cases assigned to a deactivated user will fail or go to the default owner. It does not prevent deactivation.

C & D (Opportunity/Account Teams)
Being a member of a team does not stop a user from being deactivated. Upon deactivation, they simply remain on the team record but lose access to the system.

Pro-Tip for the Exam
If you can't deactivate a user because of a blocker you can't fix immediately, you should Freeze the user account. Freezing prevents the user from logging in but doesn't solve the underlying dependency issues, allowing the administrator time to reassign dashboards or email alerts.

Reference
Salesforce Help: Considerations for Deactivating Users
Trailhead: User Management > Protect Your Data