Free Salesforce-Platform-Administrator Practice Test Questions 2026

Explanation:

B. Consultants
The AppExchange isn’t just a marketplace for installable packages; it also lists Certified Consulting Partners who can help you implement, customize, and optimize Salesforce. As an administrator looking to enhance the org, you can use the AppExchange to find and evaluate consultants by industry, product expertise (e.g., Sales Cloud, Service Cloud, Experience Cloud), geography, and customer ratings. This is especially helpful when you need strategic guidance, complex data migrations, integrations, or change management beyond point-and-click configuration. Partner listings include case studies, certifications, and verified reviews, enabling you to select a consultant who aligns with your business goals and technical requirements.

C. Components
AppExchange offers Lightning components (and other building blocks like Flow actions and templates) that admins can add to Lightning pages to extend functionality without code. These Components can deliver UI widgets (dashboards, data visualizations, guided wizards), productivity tools (address validators, calendar widgets), and service utilities (knowledge surfacing, case tools). Because components are designed to drop into the Lightning App Builder, they allow you to enhance the user experience rapidly—often with configuration only—while maintaining upgradeability and vendor support. Many providers offer freemium versions, so you can pilot enhancements safely before committing.

Why the others are not correct

A. Communities
While Salesforce’s Experience Cloud (formerly Communities) can be enhanced with AppExchange assets—such as Bolt Solutions (prebuilt site templates) and components—the term “Communities” by itself isn’t something you find as a “solution” to install from the AppExchange in the same way you’d install an app or add a consultant. You configure and license Experience Cloud within your org; the AppExchange supplements it with templates and components, but “Communities” per se is not an AppExchange item.

D. Customers
The AppExchange doesn’t provide “customers.” It’s a marketplace for apps, components, industry solutions, and consulting partners, plus reviews and listings—not a directory to acquire customers. If the goal is to enhance your organization, you’d leverage solutions (apps/components) or expertise (consultants) available there, not “customers.”

Explanation:

A validation rule is used to enforce complex data entry requirements and maintain data quality. In this scenario, the user must provide one of two pieces of information before the record can be saved.

B. Validation rule:
A validation rule formula can be created to check if both fields are simultaneously empty upon saving the record. The formula would use the ISBLANK() function for the text field and a check for the boolean value of the checkbox. If both are blank/false, the rule triggers, an error message is displayed, and the user is prevented from saving the record until at least one condition is met.
Example Logic: ISBLANK(Product_Type__c) && Needs_Review__c == FALSE

A. Before Save flow:
While a Flow can perform logic, a Validation Rule is the standard, simpler, declarative tool specifically designed to prevent records from being saved when business rules are violated and to provide immediate user feedback.

C. Workflow rule:
Workflow rules run after a record is saved and cannot prevent a save operation from occurring to enforce mandatory data entry.

D. Required fields:
Marking a field as "Required" (either via Field Level Security, Page Layout, or universally) means that field always needs a value. This requirement is conditional ("or check the Needs Review box"), so standard required fields functionality won't work alone.

Explanation:

Why:
B. Data backups are limited to weekly or monthly intervals.
With the built-in Data Export in Setup, you can schedule exports weekly or monthly (weekly in Enterprise/Performance/Unlimited; monthly in others). Manual exports are available once every 7 days (weekly) or 29 days (monthly).

D. Metadata backups must be run via a separate process.
The Data Export service backs up data (CSV + attachments), not metadata. Salesforce advises backing up metadata using a separate method (e.g., unmanaged package versions, Metadata API/VS Code, or a release-management tool).

Why the others are wrong:

A. Metadata Backups are limited to sandbox refresh intervals.
Sandbox refresh limits apply to sandboxes, not to metadata backups. Metadata backup is a separate process (e.g., unmanaged package versions/Metadata API) and isn’t constrained by sandbox refresh timing.
C. Data export service should be run from a sandbox.
The standard Data Export is run from Setup in the target org (commonly Production) and is intended to back up that org’s data. There’s no requirement to use a sandbox.

Reference:
Export Backup Data (Help): scheduling weekly/monthly, what’s included.
Trailhead – Data Export Service: cadence details and edition differences.
Back Up Metadata (Help): separate process for metadata.

Explanation:

The two correct options describe the initial enrollment process for Multi-Factor Authentication (MFA):

A. Users need to connect an authenticator app to their Salesforce account.
This is the core step of the MFA enrollment process. When a user with a mandatory MFA permission (like the one assigned) logs in for the first time without a registered verification method, they are prompted to connect an authenticator app (like Salesforce Authenticator, Google Authenticator, etc.) to their account. This connection links the app's unique secret key to the user's Salesforce profile.
C. Users need to download and install an authenticator app on their mobile device.
Since the user hasn't completed the MFA setup yet, they must first download and install an application capable of generating the one-time passwords (TOTP codes) or receiving push notifications, such as the Salesforce Authenticator app, on a mobile device. This is the prerequisite for step A (connecting the app).
Why it's important for Data Loader
Data Loader typically uses an OAuth (web-based) flow for login when MFA is enabled. When the user initiates the login in Data Loader, it opens a web browser where they enter their username and password. Because the permission "Two-Factor Authentication for API Logins" is enabled, the user is then immediately diverted into the MFA enrollment/verification flow.

❌ Incorrect Answers

B. Users need to get a security token from a trusted network using Reset My Security Token.
This is incorrect. The security token plus password mechanism is the legacy way to handle API logins for users without trusted IP ranges. When MFA for API Logins is enabled, it replaces the need to append a security token to the password. The user is required to use the MFA method (like a verification code from the authenticator app) instead.
D. Users need to enter a verification code from email or SMS, whichever has higher priority.
This is incorrect. While email or SMS codes can be used as a backup method, they are generally not considered a primary or "High Assurance" MFA method in Salesforce (and SMS verification is phased out for MFA). More importantly, the system does not use a "priority" system between email and SMS; it offers the methods the user has registered. For a first-time setup, the system guides the user to connect an authenticator app (A and C) as the standard for MFA.

References:
Salesforce Help: What Happens When You Log In with Multi-Factor Authentication (MFA)
Details the process for initial login, which requires connecting an authenticator app.
Salesforce Help: MFA for API Access
Confirms that "Two-Factor Authentication for API Logins" requires users to provide a second factor (like an authenticator app code) when accessing Salesforce via API tools like Data Loader, effectively superseding the standard security token requirement.

Explanation:

The key requirement in the scenario is to reassign all of a user's accounts and opportunities to a new sales rep while keeping the existing teams intact. The Mass Transfer tool is the native Salesforce feature specifically designed for this exact purpose.

Here’s why it's the correct choice:

Built for Reassignment: Its primary function is to transfer records from one user to another. It automatically handles the ownership change for the specified objects (in this case, Accounts and Opportunities).
Preserves Teams: This is the most critical feature for this scenario. The tool has a specific option to "Transfer related records (Contacts, Cases, and Opportunities)" and, most importantly, "Keep Account Team" and "Keep Opportunity Team". Selecting these options ensures the existing team structures on those records remain unchanged, which fulfills the business requirement perfectly.
Administrative Ease: It is a point-and-click tool accessible from Setup, requiring no data export, manipulation, or import. The administrator simply selects the user to transfer from, the user to transfer to, and the objects, then checks the boxes for the desired options.

Analysis of Incorrect Options

Why A is Incorrect (Data Loader):
While Data Loader is a powerful tool for mass updating record ownership, it is not the best tool for this specific task. Using Data Loader would require the administrator to:
Export all the departing user's Accounts and Opportunities.
Manually update the OwnerId field for every record to the new user's ID.
Re-import the data.
This process is more manual, error-prone, and does not automatically handle the preservation of teams. You would have to ensure you did not update any team-related fields, adding an extra layer of complexity.

Why C is Incorrect (Data Import Wizard):
The Data Import Wizard is designed for importing new records from a spreadsheet (e.g., leads, contacts, accounts). It is not a record reassignment tool. It lacks the specific functionality to seamlessly transfer ownership from one user to another while managing related records and teams.

Why D is Incorrect (Dataloader.io):
Dataloader.io is a third-party, cloud-based version of Data Loader. While it is an excellent tool for data manipulation, it suffers from the same limitations as the standard Data Loader (Option A) for this specific use case. It is a general-purpose data update tool, not the specialized, team-preserving transfer tool that the built-in Mass Transfer feature is.

Summary & Key Takeaways for the Exam
The Mass Transfer Tool is the go-to native feature for reassigning records from one user to another.
Its key advantage is the ability to transfer related records and preserve team membership with a single click.
While tools like Data Loader can change ownership, they should be considered a "last resort" for this task because they lack the built-in logic to handle the ancillary record relationships cleanly.

Reference:
This question tests your knowledge of Data Management tools, specifically knowing which tool to use for a standard administrative task like user deactivation and record reassignment. The Mass Transfer tool is a core part of the Platform Administrator's toolkit.

Explanation:

Sales reps are struggling to manage deals—meaning Opportunities in the pipeline—and leadership wants them to prioritize the right ones and close more. Einstein Opportunity Scoring solves this by training an AI model on the org’s historical Opportunity data (closed-won and closed-lost records).
For every open Opportunity, it generates a predictive score from 1 to 99, displayed directly on the record and in list views.

High scores (70–99, green): Signal strong alignment with past wins—reps should accelerate these.
Medium scores (40–69, yellow): Need review; contributing factors (e.g., “long time in stage”) guide action.
Low scores (1–39, red): Warn of risk; reps can either fix issues or deprioritize.

The admin enables it via Setup > Einstein > Opportunity Scoring. It requires a minimum data set (400+ Opportunities over 24 months) and is included in Sales Cloud Einstein (Enterprise, Unlimited, Performance editions).

Why the Other Options Are Incorrect:

A. Einstein Activity Capture
This feature automatically syncs emails and calendar events from Gmail/Outlook into Salesforce Activity History and Related Lists—without manual logging. It eliminates data entry so reps don’t miss logging calls or emails.
Why it doesn’t help: It improves activity visibility and compliance, not deal prioritization or win probability. A rep may have 100 logged activities but still waste time on a low-potential $1M deal stuck in “Negotiation” for 90 days. Einstein Activity Capture gives no predictive insight into which Opportunities are most likely to close.

C. Einstein Search Personalization
This uses user behavior (clicks, views, edits) to rank search results higher for records a rep interacts with often. For example, if a rep frequently views “Acme Corp,” it appears higher in global search.
Why it doesn’t help: It speeds up finding records, not evaluating or prioritizing Opportunities. A rep can instantly find 50 deals but still has no data-driven guidance on which 5 are worth calling today. Search personalization is about access speed, not strategic focus.

D. Einstein Lead Scoring
This applies AI to Leads (pre-Opportunity prospects) and assigns a score (1–99) predicting conversion likelihood to an Opportunity. It helps marketing and SDRs focus on high-quality inbound leads.
Why it doesn’t help: The problem is existing deals in the pipeline, not generating new Opportunities. Once a Lead becomes an Opportunity, Lead Scoring no longer applies. A rep with 30 open Opportunities still lacks guidance on which to push through “Proposal” or “Negotiation” stages—Einstein Opportunity Scoring takes over at that point.

Reference:
Salesforce Help: Einstein Opportunity Scoring
Trailhead: Sales Cloud Einstein Basics → Prioritize Deals with Opportunity Scoring

Explanation:

Universal Containers wants stricter user passwords to increase org security. Salesforce provides native Password Policies in Setup > Security > Password Policies that directly control password strength. The two most effective settings for enforcing stricter passwords are:

Minimum password length: Forces passwords to be longer (e.g., 12+ characters), making them harder to crack via brute force.
Password complexity requirement: Requires a mix of uppercase, lowercase, numbers, and special characters—preventing simple or predictable passwords.

These are the core mechanisms Salesforce uses to define "strict" passwords. Admins can configure both to align with security best practices (e.g., NIST guidelines).

Why the Other Options Are Incorrect:

A. Password different than username
This is a standard, non-configurable rule in Salesforce—passwords are always required to differ from the username. It cannot be "configured" and is not part of the adjustable Password Policies. Why it doesn’t help: It’s already enforced by default; selecting it as a configurable option is incorrect on the exam.
B. Prevent common words
Salesforce does not have a native setting to block common words (like “password123”) in Password Policies. This type of dictionary-based filtering is available in third-party tools or Identity providers (e.g., Okta), but not in standard Salesforce.
Why it doesn’t help: It’s not a configurable option in Setup > Password Policies, so an admin cannot enable it natively.

Reference:
Salesforce Help: Set Password Policies
Trailhead: Salesforce Security Basics → Manage Password Policies

Exam Tip:
For stricter passwords, always select Minimum length and Complexity. Options like “different from username” are default rules, and “prevent common words” is not native to Salesforce.

Explanation:

The Marketing User checkbox is a specific permission that grants a user the ability to manage campaigns, including creating, editing, and deleting them, as well as managing campaign members. Without this box checked, a user can typically only view campaigns and run reports.
Enabling this checkbox is the most direct way to give a user the ability to add and update campaign members, which is the exact issue the sales user is facing.

Why other options are incorrect:

A. Create a permission set to allow the user to edit Campaign Members:
While a permission set could theoretically be used to grant this access, the "Marketing User" checkbox is the primary and most comprehensive feature license designed for these specific campaign management capabilities.

B. Provide the user access to both Leads and Contacts to edit all Members:
Permissions for the Lead and Contact objects are separate from the permissions needed to manage Campaign Member records. Having access to a Lead or Contact does not automatically grant the ability to add or update them as Campaign Members.

D. Run a Campaign report and update any Member information via Data Loader:
This is a workaround that an administrator could perform, but it does not solve the user's inability to manage campaign members directly in the user interface. The goal is to troubleshoot the user's access, not to perform the task for them.

Explanation:

This question tests the specific prerequisites for using the LogACall and Email quick actions within the Case Feed.
The key detail is that the administrator added an Email quick action, not just any action. The standard "Email" quick action is designed to send an email and log it on the case feed as an activity.
For this specific "Email" quick action to function and be visible, the system must know which email address to use for sending and how to associate the outbound email with the case. This is configured through Email-to-Case.
Enabling Email-to-Case creates a unique email address (or addresses) for your organization's cases.
When the "Email" quick action is used from a case, Salesforce sends the email from this designated org-wide email address.
More importantly, it allows the system to link the sent email as an activity directly to the case record, ensuring it displays correctly in the Case Feed.
Without Email-to-Case enabled, the "Email" quick action will not appear on the page layout or in the publisher actions, as the necessary underlying email routing service is not active.

Analysis of Incorrect Options

Why A is Incorrect (Email Notifications):
Email Notifications are used to automatically send alerts to users (e.g., when a case is assigned to them or a comment is posted). This is a system for sending automated messages to people, not for a user to manually send an email to a customer from a case feed.

Why C is Incorrect (Email Alerts):
Email Alerts are a type of action used within Process Builder, Flow, or Workflow Rules to send automated emails. Like Email Notifications, this is an automation tool, not the configuration that enables the manual "Email" quick action.

Why D is Incorrect (Email Templates):
Email Templates are, of course, used to pre-format the content of emails. While the "Email" quick action can use an email template, the template itself does not enable the action to appear. The action will still be absent if Email-to-Case is not enabled.

Summary & Key Takeaways for the Exam
The standard Email quick action on the Case object has a hard dependency on the Email-to-Case service being enabled.
If a quick action does not appear on the page layout as expected, always check for its specific prerequisites. For the Case Email action, the prerequisite is Email-to-Case.
This is different from the "Log a Call" action or a custom quick action, which would not have this dependency.

Reference:
This question tests knowledge of Service Cloud configuration and Activity management, specifically the setup required for core Case Feed functionalities.

Explanation:

Case Escalation Rules are designed to automatically reassign or escalate Cases based on time-based criteria. In this scenario, Universal Containers wants to move unassigned Cases open for more than 2 hours to an urgent Case queue and alert the support manager. Escalation Rules allow administrators to:
Define conditions like “Case is unassigned” and “Case Age > 2 hours”
Automatically reassign the Case to a queue
Send email notifications to designated users (e.g., support manager)
This makes Escalation Rules the ideal solution for time-sensitive Case handling.

❌ A. Case Scheduled Reports
Scheduled Reports are used to automatically email reports at set intervals (e.g., daily, weekly). While they can show which Cases are overdue or unassigned, they are purely informational. They do not trigger any actions such as reassigning Cases or sending alerts. In this scenario, UC needs an automated workflow, not just visibility.

❌ B. Case Dashboard Refreshes
Dashboards provide visual summaries of Case metrics, such as average resolution time or open Case volume. Refreshing a dashboard updates the data but does not perform any automation. Dashboards are useful for monitoring performance, but they cannot move Cases or send alerts based on time-based conditions.

❌ D. Case Assignment Rules
Assignment Rules are triggered at the time a Case is created, using criteria like origin, subject, or custom fields. They do not support time-based reassignment or escalation after a Case has been open for a certain duration. In this scenario, UC needs to escalate Cases that remain unassigned for more than 2 hours, which Assignment Rules cannot handle.

Explanation:

The key term here is "wizard," which implies a multi-step, interactive, and guided experience for the user.

Flow Builder (specifically a Screen Flow type) is the only declarative automation tool in Salesforce capable of creating an interactive, multi-step screen interface.

The administrator can design a Screen Flow with multiple screen elements to guide the user through the process step-by-step:

Screen 1: Select the lost client account/opportunity.
Screen 2: Input the Reason for Loss (required fields).
Screen 3: Final review and confirmation.

Behind the scenes, the Flow can take the user's input to create a new "Lost Client" record (or update the existing Opportunity record) and handle any follow-up actions, like notifying the sales manager.

Explanation of Incorrect Answers

A. Process Builder:
This tool is for background automation (e.g., when a record is created, update a field). It cannot interact with users by displaying screens or gathering input. Salesforce is also phasing out Process Builder in favor of Flow Builder.
B. Approval Process:
This is a specialized tool for defining a sequence of steps required to approve a record. While it involves user interaction, it is not used to build an initial data entry form or a multi-step wizard.
C. Outbound Message:
This is a legacy automation action that sends a SOAP message to an external system. It is entirely for integration and has no user-facing screen component whatsoever.

Explanation:

When a user reports login failure, the fastest and most direct way to diagnose the cause is to check Login History in Salesforce. This shows the last 6 months of login attempts for the user, including date/time, status (Success/Failed), failure reason (e.g., "Invalid password", "User is frozen", "IP restricted"), source (browser, API), and login type.

The admin accesses it via:
Setup > Users > [User Name] > Login History (on the User detail page), or
Setup > Security > Login History (org-wide list, filter by username).

Common issues visible here:
Too many wrong passwords → account locked.
Login from blocked IP → login IP range restriction.
Invalid security token → API or mobile login issue.

This is the standard first step in login troubleshooting.

Why the Other Options Are Incorrect:

B. Check the attempted logins by running the setup audit trail
The Setup Audit Trail tracks configuration changes made by admins (e.g., profile edits, field updates), not user login attempts or failures.
Why it doesn’t help: It contains zero information about authentication events or user login issues.

C. Pull the password history to ensure the password policy was followed
Salesforce does not allow admins to view password history for any user due to security and compliance. Password policies are enforced on reset, but there’s no report or log of past passwords.
Why it doesn’t help: This data is inaccessible and irrelevant to diagnosing current login failure.

D. Reset the security token for the profile
Security tokens are per user, not per profile. Also, resetting a token is an action, not a diagnostic step—and only needed if the user is logging in via API or desktop client with a known valid password.
Why it doesn’t help: It skips troubleshooting and assumes the cause; Login History would confirm if token is the issue first.

Reference:
Salesforce Help: View Login History
Trailhead: Salesforce Security Basics → Monitor Login Activity

Exam Tip:
User can’t log in? → Always start with Login History (user-level or org-wide).
Audit Trail = config changes only. Password history = not viewable. Security token = per user, not profile.