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

Explanation:

Why this is correct

To access Lightning Experience, a user must have the “Lightning Experience User” permission enabled.

This permission:

Controls whether a user can access the Lightning interface
Can be granted via:
Profile, or
Permission set (commonly used in this scenario)

In this question:

Users were given a Minimum Access Salesforce profile (which is intentionally very limited)
Even though permission sets were assigned, they still don’t have Lightning access
So the missing piece is explicitly enabling Lightning Experience User

Why the other options are incorrect

A. Enhanced Interface for User Access Policies
This does not exist as a setting controlling Lightning access.

B. Add Lightning component to a layout
Components affect page content, not whether Lightning Experience is available.

C. Create a page in Lightning App Builder with the org as default
Lightning pages control UI layout, not the user’s ability to access Lightning itself.

Key ADM-201 concept

To access Lightning Experience, users need:

✔ The Lightning Experience User permission

Everything else (apps, pages, components) only controls what they see after they are already in Lightning.

Exam tip

If a question says:

“Users cannot see Lightning interface at all”

The answer is almost always:

Enable Lightning Experience User permission

Explanation:
Agentforce (Salesforce's suite of autonomous AI agents) excels at handling dynamic, multi-step processes that require real-time adaptation based on user input, context changes, or intermediate outcomes. Unlike rigid automation, Agentforce can reason, retrieve data, and adjust its workflow, making it ideal for complex service or sales scenarios.

Correct Option: C

Multi-step processes that need adaptation to change are Agentforce's sweet spot.

Examples: troubleshooting a technical issue where each answer changes the next question, or a loan application that requires different documentation based on customer profile.

Agentforce uses generative AI and deterministic flows to decide next steps dynamically, not follow a fixed path.

This adaptability distinguishes Agentforce from simple rule-based automation.

Incorrect Option: A

Single-step predefined processes are too simple for Agentforce.

These are better handled by standard automation like Workflow Rules, Process Builder, or basic Flows.

Deploying an AI agent for a single, unchanging step (e.g., "send auto-reply email") is over-engineering and inefficient.

No adaptation or decision-making is required, so Agentforce adds no value.

Incorrect Option: B

Static document generation (e.g., merging data into a PDF template) follows predictable, rule-based logic.

Tools like Salesforce Documents, Conga, or DocuSign are purpose-built for this.

Agentforce can assist in requesting a document, but the generation itself is not its strength—it lacks the deterministic merge template engine native to dedicated tools.

Incorrect Option: D

Tasks without decision-making are purely transactional or linear (e.g., record creation, field update).

Agentforce is designed to navigate decisions, uncertainty, and branching logic.

Using AI where no decision is needed wastes API calls and compute resources while adding latency.

Simple automations or Quick Actions are more appropriate.

Reference:
Salesforce Help Article: Agentforce Capabilities – Agentforce is optimized for complex, multi-step workflows that require real-time adaptation, reasoning, and dynamic decision-making. Repetitive, single-step, or purely deterministic tasks are better suited for standard automation tools like Flows or Workflow Rules.

Explanation:

Why this is correct

In Salesforce, data visibility in reports is controlled by the sharing model (record-level access).

To ensure that:
“only the financial records belonging to each individual user are visible”
you must enforce record-level security so users can only see their own records.
Setting the object’s OWD (Organization-Wide Default) to Private means:

Users can only see records they own (unless explicitly shared)
This directly satisfies the requirement for strict data privacy

Why the other options are incorrect

Public Read/Write
This would expose all records to all users. Completely opposite of the requirement.

Create multiple reports filtered per user
This is not secure data control. Users could still create or modify reports unless underlying access is restricted. Reporting filters do NOT enforce security.

Apex sharing
Used for custom, programmatic sharing. Not needed when standard sharing model (OWD = Private) already solves the requirement. Over-engineered for this scenario.

Key ADM-201 takeaway
Reports do not enforce security — sharing rules do
If a question is about:

“who can see records”
“data privacy”
“only owner should see records”

👉 Think: Organization-Wide Defaults = Private

Explanation:

The Mass Transfer Records tool is specifically designed for exactly this scenario — reassigning ownership of records from one user to another. It's a native, declarative Salesforce feature available in Setup that allows an administrator to:

Transfer all records (Accounts, Leads, Opportunities, Cases, custom objects) owned by one user to another user.

Optionally transfer associated "child" records (like Opportunities and Cases under an Account).

Transfer open and/or closed records.

Maintain the existing sales team configurations and other record details.

This makes it the perfect, purpose-built tool for bulk ownership transfer when a sales rep leaves the company.

Why the other options are wrong

A – Data Loader
Data Loader is a powerful data manipulation tool, but using it for ownership transfer would require manually exporting all records, updating the OwnerId field in a CSV file, and re-importing them. This is unnecessarily complex, error-prone, and time-consuming compared to Mass Transfer Records. It also doesn't elegantly handle related child records.

B – Dataloader.io
Same limitations as Data Loader above — it's a third-party ETL tool. While capable, it's overkill and less efficient for a simple ownership reassignment task. Mass Transfer Records is the right native tool.

D – Data Import Wizard
The Data Import Wizard is for importing new or updating existing records from a file. It's not designed for transferring ownership in bulk. You'd need to export, modify, and re-import, facing the same challenges as the Data Loader options.

Reference
Salesforce Help: Mass Transfer Records
Salesforce Help: Transferring Records from One User to Another

Explanation:

DreamHouse Realty needs a templated process that includes a mortgage calculator capable of generating Leads for loans. The project must be completed in 30 days with no additional budget left for the year.

Flow Solutions (available on the Salesforce AppExchange) are the best fit because:

They are pre-built, ready-to-install Flows (often provided by Salesforce Labs or partners).

Many include complex, functional components such as calculators, guided processes, and Lead creation logic.

They can be installed quickly, then lightly customized by a Platform Administrator using Flow Builder.

Most good Flow Solutions are free, which aligns perfectly with the “maxed out budget” constraint.

This allows rapid deployment (well within 30 days) without needing custom development.

There is even a real "Mortgage Calculator with Lead Generation Flow" available as a Flow Solution on AppExchange, which matches this requirement almost exactly.

Why the other options are incorrect

A. Bolt Solutions
Bolt Solutions are pre-built, industry-specific templates (often full apps or packages) aimed at faster implementations. They tend to be more comprehensive (and sometimes paid) and are not specifically focused on individual templated processes like a mortgage calculator flow.

B. Lightning Community (now Experience Cloud)
This is for building customer portals or external sites. While you could embed a flow in a community, it does not provide the mortgage calculator logic or templated lead-generation process itself.

C. Lightning Data
Lightning Data is for enriching your Salesforce data with third-party data (e.g., company information, contact data). It has nothing to do with building a calculator or automated process.

Key Takeaway for ADM-201

When the exam mentions a tight timeline + zero budget + templated/automated process (especially involving screens, calculations, and record creation), the recommended approach is usually to leverage pre-built Flow Solutions from the AppExchange.

Reference:
AppExchange Overview
Flow Builder & Automation
Sales and Marketing Applications (Lead generation)

Explanation:

To ensure that a field is populated regardless of how the data enters the system (e.g., via the Salesforce UI, the Data Loader, or an external API/billing system integration), you must enforce the requirement at the database level.

Why D is correct
A Universally Required field ensures that the record cannot be saved without a value, no matter the source. Because Northern Trail Outfitters is pushing data from an external billing system, the record might not pass through the standard Page Layout where UI-based requirements exist. A universally required field ensures data integrity at the database level, preventing the record from being created if the "Billing System" field is null.

Why others are incorrect

A
While a Flow could be used to populate a field, it is overly complex for a simple requirement and can be bypassed depending on how the record is created.

B
Marking a field as "Required" on a Page Layout only enforces the requirement in the Salesforce user interface. It does not prevent a record from being created via an API call from an external system.

C
Approval processes are for business logic and workflows, not for data entry validation.

Key Concepts

Universally Required Fields
These are enforced at the field level, not the layout level. They guarantee the field is never empty in the database, making them the most robust option for data integrity.

Page Layout Requirements
These are enforced in the UI only. They are a "soft" requirement that can be bypassed by APIs, imports, or other automated processes.

Data Entry Points
In Salesforce, records are often created via various channels. A strong administrator always considers whether a requirement needs to be enforced system-wide (API + UI) or just for manual entry.

Reference
Make Fields Required for Data Quality

Explanation:
Best practices for Agentforce instructions require clarity on data format, source (e.g., conversation history or user input), and whether the input is required or conditional. Instructions must leave no ambiguity for the AI agent to correctly extract or request values from the conversation context.

Correct Option: D

Clear format: Specifies "18 character ID" and "three-digit code" — precise length and type.

Data source: Tells the agent where to find the productId (conversation history or user input).

Conditional requirement: States reasonCode is required only when productId is present, preventing unnecessary prompts.

Explicit required flag: Uses "Required" for productId, ensuring the agent does not proceed without it.

Follows Agentforce best practices for actionable, unambiguous instructions.

Incorrect Option: A

Lacks data source guidance (e.g., conversation history vs. user input).

No clarity on whether inputs are required or optional.

"Numerical code" is too vague — does not specify three-digit length or conditional logic.

Agent may guess incorrectly or ask for missing information inefficiently.

Incorrect Option: B

Missing explicit format details (e.g., "18 characters" for productId, "three-digit" for reasonCode).

No mention of whether reasonCode is conditional or always required.

Lacks a "Required" flag for productId, so agent might proceed without it if not found.

Incomplete for production-grade reliability.

Incorrect Option: C

Extremely vague — "ID from the product record" does not specify 18-character format.

"Code for the reason" lacks length (three-digit) and conditional requirement logic.

No data source instructions (conversation history or user input).

High risk of agent extracting wrong values or failing to extract at all.

Reference:
Salesforce Trailhead: Build Effective Agentforce Instructions – Best practices include specifying exact data formats (length, type), identifying data sources (conversation history, user input, or record fields), and using conditional requirements to guide agent behavior. Vague instructions lead to extraction failures or incorrect data.

Explanation:

Salesforce provides administrators with the “Login As” feature, which allows them to log in as a specific user without needing that user’s password. This is the safest and most effective way to troubleshoot issues because the admin can replicate the exact experience of the user — including their profile, permissions, page layouts, and any validation rules or restrictions that apply.

In this case, the VP of Sales is encountering an error when saving an opportunity, but the admin is not. By using Login As, the administrator can see the error firsthand and identify whether it’s caused by profile restrictions, validation rules, required fields, or other configuration differences.

Why not the other options?

Log in as a system administrator to troubleshoot
The admin already did this, but it doesn’t replicate the VP’s profile or permissions.

Use an AppExchange product to troubleshoot
Not necessary; Salesforce has built-in tools for this.

Ask the user for their password so the admin can log in as the user
This is a security violation and against Salesforce best practices.

Reference
Salesforce Help: Login as Another User

Explanation:
Best practices for prompt engineering in Agentforce emphasize clarity, simplicity, and natural language. AI agents respond more reliably when prompts use plain, conversational terms and direct instructions. Overly complex, technical, or theoretical prompts increase ambiguity and reduce the accuracy of step-by-step troubleshooting responses.

Correct Option: D

Natural, easy-to-understand language reduces misinterpretation by the AI model.

Clear, concise instructions help the agent produce predictable, actionable troubleshooting steps.

Avoids confusion caused by jargon or ambiguous phrasing.

Aligns with Salesforce's recommended prompt design principles for service agents.

Makes prompts easier for administrators to maintain and debug over time.

Incorrect Option: A

Detailed prompts with multiple nested conditions become difficult to manage and prone to errors.

AI models can struggle with overly complex conditional logic embedded in natural language.

Troubleshooting scenarios are better handled by breaking conditions into separate prompts or using deterministic flows.

Violates the KISS (Keep It Simple) principle in prompt engineering.

Incorrect Option: B

Specific technical terms and abbreviations may be unfamiliar to the AI or misinterpreted.

Customers and service reps often use layman's terms; the AI must match that language.

Specialized jargon does not improve AI understanding unless the model was specifically fine-tuned on that domain.

Reduces accessibility for non-technical administrators maintaining the prompt.

Incorrect Option: C

High-level, theoretical concepts give the AI too much creative freedom.

For troubleshooting, what is needed is precise, step-by-step instructions, not conceptual flexibility.

Creative responses risk incorrect or unsafe technical guidance.

Best for brainstorming or summarization tasks, not for operational troubleshooting.

Reference:
Salesforce Help Article: Best Practices for Prompt Builder – Use clear, natural language and concise instructions. Avoid complex nested logic, excessive technical jargon, or abstract concepts when precision is required. Simple prompts yield more reliable and predictable agent responses.

Explanation:

The Marketing User profile is a standard profile in Salesforce. By default, standard profiles have specific permissions tailored to their namesake roles; however, they can be cloned and edited (or in some cases, have their permissions adjusted) to meet business needs.

To ensure marketers can maintain campaign relationships on opportunities, they need Object-Level Permissions (Read and Edit) on the Opportunity object itself.

Profile-level permissions determine what a user can do with records of a specific object. Since the requirement is to give a group of users (those with the Marketing User profile) access, editing the profile's object permissions is the most direct way to satisfy the requirement in a new instance.

Why other options are incorrect

B (Add a custom permission set)
While this could work, the question asks what the administrator should do next after having already decided to assign the Marketing User profile. Adjusting the profile they are already using is the more streamlined administrative step in this context.

C (Edit the role)
Roles in Salesforce control Record-Level Access (which specific records you can see), not Object-Level Access (whether you can see the Opportunity tab or edit any opportunities at all).

D (Configure assigned apps)
This only controls the visibility of the app in the App Launcher and the tabs available in the navigation bar. It does not grant the underlying permission to "Read" or "Edit" the records.

Pro-Tip for the Exam

Always remember the "Security Sandwich":

Profiles/Permission Sets: Control what a user can do (Object/Field permissions).
Organization-Wide Defaults (OWD) & Roles: Control which records they can see (Record-level access).

Reference
Salesforce Help: Standard Profiles
Trailhead: Data Security > Control Access to Objects