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

Explanation:
When an Agentforce agent (e.g., an Einstein Bot) is deactivated, it cannot be invoked for new conversations. However, any ongoing, active chat sessions that began before deactivation continue using the existing agent configuration until the conversation naturally ends. Deactivation does not abruptly terminate live sessions.

Correct Option: B

Deactivating an agent prevents new conversations from starting with that agent.

Ongoing conversations continue uninterrupted because the session state and agent logic are already loaded.

The agent remains available to those active users until they end the chat or the session times out.

This ensures customers are not disconnected mid-issue when administrators make configuration changes.

Incorrect Option: A

The agent does not pause conversations upon deactivation.

There is no automatic resume mechanism tied to reactivation.

Pausing is not a feature of agent deactivation; ongoing chats simply proceed with the existing logic.

Incorrect Option: C

The agent window does not automatically close.

Closing would cause data loss and poor customer experience.

Users can still send and receive messages within the active session.

Incorrect Option: D

The agent does not send system error messages when messages are received during an ongoing conversation after deactivation.

The agent continues to respond using its last published configuration.

Error messages would only appear if the agent's underlying action or flow fails.

Reference:
Salesforce Help Article: Deactivate an Einstein Bot – When you deactivate a bot, new chat sessions cannot start. However, any active chat sessions that began before deactivation remain active and continue using the deactivated bot until those sessions end naturally.

Explanation

Why this is correct

Freezing a user in Salesforce:

Immediately prevents the user from logging in
Keeps the user record active
Preserves ownership of records, reports, dashboards, etc.

This is ideal for temporary situations like a leave of absence, because:

You can unfreeze later without reconfiguration
No disruption to data ownership or automation

Why the other options are incorrect

Reassign the user’s license
Not practical for temporary leave. Can break functionality and requires reassigning later.

Change Login Hours
Only restricts access to certain times. User could still log in during allowed hours.

Restrict Login IP Addresses
Limits where users can log in from. Does not fully block access (they could still log in from allowed IPs).

Key ADM-201 takeaway

Freeze = temporary login block (best for leave)
Deactivate = permanent removal of access

Exam tip

If the question says:

“temporary”
“leave”
“should not log in but keep user”

👉 The answer is almost always Freeze User

Explanation:
Agentforce SDR (Sales Development Representative) is an autonomous AI agent designed to engage, qualify, and nurture leads without human intervention. It can have natural, two-way conversations with leads, answer product or company questions using trusted data sources (grounding), and book meetings or route qualified leads to human reps.

Correct Option: D

Agentforce SDR answers lead questions with responses grounded in company data (e.g., Knowledge articles, product specs, pricing guides).

Uses retrieval-augmented generation (RAG) to ensure accuracy and prevent hallucination.

Operates autonomously 24/7 to nurture leads, qualify them, and hand off to human sales reps when ready.

This is the core purpose of Agentforce SDR — intelligent, data-backed conversation with potential customers.

Incorrect Option: A

Generating a dynamic call script for human sales reps is not the function of Agentforce SDR, which is autonomous.

That describes sales enablement tools or conversation intelligence platforms (e.g., Salesforce Sales Engagement).

Agentforce SDR is the conversational agent, not a coaching tool for humans.

Incorrect Option: B

Autonomously negotiating pricing and closing deals is not within Agentforce SDR's scope.

Pricing negotiation typically requires human judgment, approval workflows, and complex business rules.

Agentforce SDR qualifies and books meetings; closing deals remains a human-led process.

Incorrect Option: C

Analyzing human sales rep performance and providing coaching tips is a function of conversation intelligence or sales performance management tools (e.g., Salesforce Call Coaching & Scorecards).

Agentforce SDR does not monitor or coach human reps; it engages directly with leads.

This option confuses AI for sales reps with AI for sales management.

Reference:
Salesforce Help Article: What is Agentforce SDR? – Agentforce SDR is an autonomous AI agent that engages leads in natural conversation, answers their questions using grounded company data, and qualifies them for human sales reps. It does not close deals or coach human reps.

Explanation

Even though Tasks and Events are both part of the "Activity" object family in Salesforce, they each have their own separate Subject picklist field. The administrator can independently configure:

Task Subject picklist — to include "Schedule Site Visit" and "Send Contract"
Event Subject picklist — to include "Site Visit" and "Ride Along"

This is done by navigating to:

Setup → Customize → Activities → Task Fields → Subject (for Tasks)
Setup → Customize → Activities → Event Fields → Subject (for Events)

This approach gives the administrator exactly what's needed: different prepopulated subject values for each type of activity, without mixing them together.

Why the other options are wrong

A – Add the new values to the predefined field values for the global actions New Event and New Task
Global actions can have predefined field values, but these are for setting default values when a user initiates the action, not for defining the available picklist options for the Subject field. The picklist values themselves must be configured on the field definition.

C – Create a new custom Subject picklist field on Activity and add the field values
Activity is not a customizable object in the same way as standard or custom objects. You cannot create custom fields directly on the Activity object. Tasks and Events have their own standard Subject fields that are designed to be customized independently. Creating a new custom field would replace the standard Subject field functionality, which is unnecessary and non-standard.

D – Include Schedule Site Visit, Send Contract, Site Visit, and Ride Along picklist values for the Activity subject field
There is no single "Activity subject field" that applies to both Tasks and Events. If all four values were added to both the Task Subject field and the Event Subject field, users creating a Task would also see "Site Visit" and "Ride Along" (which should only be for Events), and vice versa. This doesn't meet the requirement of having distinct subjects per activity type.

Reference

Salesforce Help: Customize Task and Event Fields

The Subject field is a standard picklist available on both the Task and Event objects, and each is customized separately.

Explanation:

In Salesforce, "Critical Updates" (now formally referred to as Release Updates) can significantly change how features behave, how security is enforced, or how API integrations communicate. Never activate these directly in your production environment without testing.

Why C is correct

Activating in a Sandbox allows you to test the update in an environment that mimics production but contains non-production data. This lets you identify potential issues—such as broken flows, failing integrations, or disrupted user processes—before they impact your actual business operations.

Why others are incorrect

A
While you could let them auto-activate, relying on auto-activation is poor administrative practice. You lose the chance to identify and fix issues before they go live.

B
Activating in production without prior testing is extremely high-risk and violates best practices for change management.

D
Similar to A, allowing auto-activation in production (or generally) is a failure to perform due diligence and could lead to system downtime or data errors.

Key Concepts

Release Updates
These are pre-deployment changes that Salesforce releases to improve security, performance, or functionality. They often have an "Auto-Activation Date" after which Salesforce will force the update on all organizations.

The Sandbox Strategy
A full sandbox is an exact copy of your production environment. If a critical update is major, it is best practice to test it in a Full or Partial Copy sandbox to ensure that custom code, workflows, and integrations continue to function as expected after the update.

Change Management
As an administrator, your primary goal is to ensure business continuity. Testing is the most important step in the release cycle.

Reference
Manage Release Updates

Explanation:
Best practices for Agentforce Action Instructions require clarity on what the action does, its goal, and when the agent should invoke it. Instructions must include explicit trigger conditions to prevent the agent from calling the action in inappropriate contexts (e.g., when a customer is just asking for store hours or product availability).

Correct Option: D

Clear function: "Updates the shipping address for a customer order" — specifies what the action modifies.

Goal statement: "The goal of the action is to modify the address on a customer's record" — explains purpose.

Explicit trigger condition: "The agent should only use this action when the user explicitly requests to change their address" — prevents misuse.

Follows the "when to use" best practice, reducing false positives.

Incorrect Option: A

Lacks any trigger condition or "when to use" guidance.

"Any changes" is overly broad — agent might call it when customer mentions address casually (e.g., "I live in Texas").

No goal statement explaining why the action exists.

Too vague for reliable agent decision-making.

Incorrect Option: B
Includes an incorrect constraint: "Only use this when a customer does not have an active order" — this is likely wrong for an ecommerce context (address updates often require active order check or are blocked during active orders).

No goal statement.

Provides a negative condition without explaining intended use case clearly.

Incorrect Option: C

Missing an explicit trigger condition or "when to use" clause.

Goal statement is weak ("make sure the address is current and accurate") — describes maintenance, not customer-requested change.

Agent may confuse this with a verification or validation action, not an update action.

Reference:
Salesforce Trailhead: Build Actions for Agentforce Agents – Best practices for Action Instructions include: (1) state what the action does, (2) state the goal of the action, and (3) specify when the agent should use it, ideally with explicit trigger language like "only use when the user explicitly requests..."

Explanation:

When the Organization-Wide Default (OWD) is set to Private, users can only see records they own or records owned by people below them in the role hierarchy.

To allow a user (like the VP of Sales) to see records owned by individuals in "various parts" of the hierarchy (such as peer branches or unrelated departments), you must "open up" access. Sharing Rules are the primary tool used to grant exceptions to Private OWDs based on record ownership or criteria.

Why other options are incorrect

A (Field-Level Security)
This controls whether a user can see a specific field (like "Social Security Number") on a record they already have access to. It does not grant access to the record itself.

C (Permission Sets)
While Permission Sets grant Object-Level access (e.g., "I can read Opportunities"), they do not override Record-Level security (e.g., "I can see this specific Opportunity"). Only the "View All" permission in a Permission Set would work, but that is usually too broad for a standard request.

D (Restriction Rules)
These do the opposite of what is requested. They are used to further restrict access for certain users, not to grant more access.

Pro-Tip for the Exam

Always look at the OWD first. If it's Private, your solution will almost always involve Sharing Rules, Role Hierarchy, or Manual Sharing to grant additional access.

Reference
Salesforce Help: Sharing Rules
Trailhead: Data Security > Create Sharing Rules
Ready for the next question, or do you want to review the difference between Criteria-Based and Owner-Based sharing rules?

Explanation:

Delegated administrators have the ability to assign permission sets to users within their scope, but they cannot create, edit, or modify the configuration of permission sets themselves. This is a key limitation designed to maintain security—delegated admins can grant access using pre-configured permission sets, but they cannot alter what those permission sets actually grant. This matches option C exactly.

Why the other options are wrong

A – Delegated administrators can unlock users but cannot reset passwords
This is incorrect. Delegated administrators can both unlock users AND reset passwords for users within their designated roles. Both capabilities are fundamental user administration functions granted to delegated admins.

B – Delegated administrators can update field-level security on standard objects
This is incorrect. Delegated administration for object management is limited to custom objects only—delegated admins cannot manage standard objects. Field-level security changes on standard objects require full administrative permissions.

D – Delegated administrators cannot assign users to profiles
This is incorrect. Delegated administrators can assign users to profiles, but only to profiles specifically granted as "Assignable Profiles" in the delegated administration group configuration. They cannot assign profiles with the "Modify All Data" permission (e.g., System Administrator profile).

Key Delegated Administrator Limitations to Remember
Cannot modify permission sets (only assign them)
Cannot manage standard objects (custom objects only)
Cannot assign profiles containing "Modify All Data"
Cannot create or modify relationships on custom objects
Cannot set org-wide sharing defaults

Reference
Salesforce Help: Delegate Administrative Duties

Explanation:

This is a classic Salesforce Administrator scenario involving Business Hours.

Ursa Major Solar has reps in different time zones (Pacific Time and Eastern Time). The Eastern Time reps need business hours that start 3 hours earlier than the Pacific Time reps.

Best Practice & Correct Approach

Salesforce allows you to create multiple Business Hours records. Each Business Hours record can have its own:

Time zone
Operating hours (Start time & End time)
Business days

In this case, the Platform Administrator should:

Create one Business Hours record for Pacific Time (9:00 AM – 5:00 PM PT)
Create another Business Hours record for Eastern Time (6:00 AM – 2:00 PM ET) — which is 3 hours earlier than PT.

This way, each group of reps can be assigned the appropriate Business Hours based on their time zone.

Why the other options are incorrect

A. Adjust the current business hours to accommodate the Eastern time zone
Incorrect. Changing the existing Business Hours would negatively impact the Pacific Time reps. You cannot have one set of hours that works correctly for two different time zones with different start times.

B. Allow the reps to set business hours manually
Not possible and not a good solution. There is no “manual” setting for business hours by individual users. Business Hours are configured at the organization level.

C. Set temporary business hours for each time zone
Incorrect. Temporary Business Hours are meant for short-term exceptions (e.g., holidays, office closures). They are not suitable for ongoing, permanent differences due to time zones.

Key Takeaway for ADM-201
Always create separate Business Hours records when you have users working in different time zones with different operating hours.

Business Hours are commonly used for:

Case Escalation Rules
Entitlements & Milestones
SLA calculations
Omni-Channel routing

Where to configure
Setup → Quick Find → Business Hours

Explanation:
Agentforce in a sales organization is designed to augment sales teams by handling repetitive, high-volume tasks that do not require deep human judgment. Automating lead qualification—such as engaging inbound leads, asking qualifying questions, scoring leads, and scheduling meetings—is a prime use case that saves sales reps significant time.

Correct Option: D

Automating Lead Qualification is a key Agentforce sales use case.

Agentforce can engage leads via chat or email, ask BANT (Budget, Authority, Need, Timeline) questions, and update lead scores automatically.

It qualifies or disqualifies leads based on predefined criteria and books meetings for qualified leads.

This allows human sales reps to focus only on sales-ready opportunities.

Incorrect Option: A

Generating cold calls is not an Agentforce use case.

Agentforce interacts with customers who initiate conversation or are engaged through approved channels; it does not proactively make outbound phone calls.

Cold calling remains a human-led activity, though AI may assist with call scripts or dialers.

Incorrect Option: B

Automating all marketing content is not within Agentforce's scope.

Content creation (blogs, emails, social posts) is typically handled by marketing automation tools (e.g., Marketing Cloud, Pardot) or generative AI tools like Einstein GPT for Marketing.

Agentforce focuses on conversational engagement, not mass content production.

Incorrect Option: C

Providing basic web bot chats is too narrow and generic.

While Agentforce can power web chat, this describes a capability, not a specific sales use case.

Basic chat could apply to service, HR, or IT use cases. The question asks for a sales organization use case, where lead qualification is more specific and valuable.

Reference:
Salesforce Help Article: Agentforce for Sales Use Cases – Agentforce automates lead qualification, handles initial prospect conversations, schedules meetings, and updates CRM records. It does not generate cold calls, automate all marketing content, or merely provide basic chat.