Free Salesforce-Platform-Administrator Practice Test Questions 2026

Explanation:

The requirement is for a sales manager to view a report on all shoe records owned by their team. With the Organization-Wide Default (OWD) set to Private, users can only see records they own, unless other sharing mechanisms are in place. The Role Hierarchy is the key sharing tool here, but the question focuses on the report itself.

Let's break down each necessary configuration:

A. Custom report type.
Correct. To create a report on the custom Shoe object, you must first have a report type that includes it. The administrator may need to create a custom report type (e.g., "Shoes with Owners") that includes the Shoe object and the related User (Owner) fields to allow for filtering and displaying owner information.
B. Folder access.
Correct. For the sales manager to even see and run the report, they must have access to the folder where the report is saved. The administrator must ensure the report is in a public folder where the sales manager's profile has at least "View" access.
D. Field level security.
Correct. The sales manager's profile must have Field-Level Security (FLS) set to "Visible" for the fields on the Shoe object that are included in the report. Even if they have access to the record via the role hierarchy, if FLS hides a field, it will not appear in their report.

Let's break down why the other option is incorrect:

C. Report subscription.
Incorrect. A report subscription automatically emails a snapshot of the report to a user on a schedule. It is a feature for receiving reports, not a tool for granting the initial permission to view or run the report. A user must already have access to a report to be able to subscribe to it.
The Missing Piece: Role Hierarchy
It's critical to note that while not listed in the answers, the Role Hierarchy is the fundamental reason the manager can see the data. In an OWD Private model, the role hierarchy grants managers inherent Read access to records owned by users below them. The configurations in A, B, and D are what allow the manager to consume that data through a report.

Summary:
To provide appropriate access to the report, the administrator must ensure:
A report type exists for the Shoe object (A).
The manager can see the fields in the report (D).
The manager can find the report in a shared folder (B).

Reference:
Salesforce Help: "How the Role Hierarchy Controls Access to Records"
Salesforce Help: "Control Access to Reports and Dashboards in Folders"
Salesforce Help: "About Field-Level Security"

Explanation:

When changing the data type of a field from Auto Number to Text in Salesforce, the existing field values will remain unchanged. The Auto Number field, which generates unique, sequential values (e.g., INV-001, INV-002), will retain those values as text strings after the conversion. However, the field will no longer automatically generate new sequential values for new records; it will function as a standard text field moving forward, allowing manual entry of values. This change is permitted in Salesforce, but administrators should be cautious because:
The change is irreversible in some cases (you may not be able to revert to Auto Number).
Any automation, reports, or processes relying on the Auto Number format may need updates.
New records will not automatically receive formatted values, so manual input or other automation (e.g., Flow or Apex) may be needed to replicate the previous behavior.

Why not the other options?
B. Existing field values will be Converted: This is incorrect because the values are not "converted" in the sense of being reformatted or modified; they remain exactly as they were (e.g., INV-001 stays INV-001).
C. Existing field values will be deleted: This is incorrect because Salesforce preserves existing data during this type of field change.
D. Existing auto number field to Text is prevented: This is incorrect because Salesforce allows changing an Auto Number field to a Text field, provided the user has the necessary permissions.

Reference:
Salesforce Help: Change the Field Type of a Custom Field
Salesforce Documentation: Notes on Changing Custom Field Types

Explanation:

Why C Is Correct
The Sales manager wants quick viewing and inline editing of Opportunities closing in the next 90 days. A custom list view on Opportunity with filter Close Date equals NEXT 90 DAYS gives users an instant, filterable view of their pipeline. Enabling Kanban (available in Lightning Experience) turns the list into a visual board grouped by Stage, allowing users to drag-and-drop Opportunities to update Stage (and other fields via inline edit) — all from one screen, without opening records. This is fast, visual, and editable, perfectly matching the request.

Why A Is Incorrect
A scheduled report delivers a static snapshot via email — users can view data but cannot edit inline. It requires opening each record individually and is not a “quick way” to manage live pipeline updates. Reports are for analysis, not real-time editing.

Why B Is Incorrect
Sales Console supports multiple tabs, but opening one tab per Opportunity is inefficient and cumbersome for dozens of records. It does not provide a consolidated, editable view of the 90-day pipeline and forces record-by-record navigation — the opposite of “quick.”

Why D Is Incorrect
A dashboard component displays aggregated or visual data (charts, metrics) but does not allow inline editing of individual records. Users would see a summary (e.g., total value) but still need to navigate to list views or records to make changes — not a direct editing solution.

Reference:
“Kanban view lets you visualize and update records by dragging them between columns… You can edit fields inline without opening the record.”
— Salesforce Help: Use Kanban View

Verification Steps
Go to Opportunity tab → List Views → Create New View.
Name: “Closing in 90 Days”; Filter: Close Date equals NEXT 90 DAYS → Save.
Open the list → Click Kanban icon → Group by Stage → Drag Opportunities to update.
Confirm Stage and other fields update inline instantly.

Explanation:

Marking a field as "Required" in Object Manager is a powerful but specific action. It's crucial to understand its scope and limitations.
B. The field is universally required to save a record on that object. This is the primary function of the "Required" setting in Object Manager. It enforces a validation rule at the database level. This means every record of that object must have a value in this field, regardless of how the record is created (UI, API, import wizard, etc.) or which page layout is used.
D. The field is optional when saving records via web-to-lead and web-to-case. This is a key exception to the universal rule. The Web-to-Lead and Web-to-Case tools are designed to capture information from public forms on a website. To prevent failed submissions and lost leads/cases due to blank required fields, Salesforce treats fields marked required in Object Manager as optional for these specific tools. You must use the "Required" checkbox within the Web-to-Lead or Web-to-Case setup wizard itself to make a field mandatory for those forms.

Why the Other Options Are Incorrect:
A. The field is not required to save records via the API on that object. This is incorrect. A field marked as required in Object Manager is enforced at the database level. Any attempt to save a record—whether through the user interface, Data Loader (API), or any other API integration—will be rejected if that required field is blank. The API must provide a value for it.
C. The field is added to every page layout on that object. This is incorrect. Object Manager controls the field's schema (e.g., data type, requirement), but it does not manage page layouts. Page layouts are configured separately. When you make a field required, it does not automatically add it to any layout. Conversely, you can add a non-required field to a page layout and mark it as "Required" on that specific layout, which only affects the UI, not the database.

Reference:
Salesforce Help: "Make Fields Required"
This article explains that making a field required "ensures that users can’t save a record without entering a value." It also specifically notes the exception for Web-to-Lead: "If you add a required field to your web-to-lead form, the field is automatically treated as not required to avoid generating errors when leads are created."

Explanation:

Why this is correct
In a Screen Flow, you can control when fields appear using Conditional Visibility—a feature in the Flow Builder screen configuration.

Here’s how to do it:
On your flow screen, add the Lead Source picklist.
Add another picklist for Specific Search Engine.
On the Specific Search Engine component, set its visibility rule to display only when Lead Source equals “Search Engine.”
Mark the Search Engine field as Required = True—so it’s enforced only when visible.
This approach keeps everything on one clean screen, avoids unnecessary branching, and gives users a simple, dynamic experience.

Why the others don’t fit
A. Assign a decision element to direct the user to a second screen
A Decision element can branch the flow, but that’s overcomplicated here. It would send the user to a separate screen only for “Search Engine,” which makes the flow clunky and harder to maintain. Conditional visibility on a single screen is the standard and cleaner method.

B. Use an Assignment element
Assignment elements are used to set variable values in the background, not control screen behavior. They can’t hide or show fields on a screen based on input conditions.

D. Configure a validation rule
Validation rules run after record save (on the object), not inside a screen flow. They can ensure data quality, but they can’t hide fields or control what appears to the user while filling out a screen.

Key takeaway
✅ Use Conditional Visibility on the flow screen.
✅ Keep it on one screen for better UX.
✅ Avoid unnecessary decision branching or validation rules for UI logic.

Explanation:

The key factors in this scenario are the volume of records (300 accounts with contacts) and the requirement to load them "at one time" (i.e., a single, bulk operation).
Data Loader is the correct tool because it is designed for handling large-scale, complex data operations. It can import up to 5 million records at a time. Crucially, it can be used to import accounts and contacts in separate operations, maintaining the relationship between them by using External IDs and the Salesforce ID of the newly created account records.

Why the Other Options Are Incorrect:
A. Dataloader.io:
This is a powerful third-party application (from MuleSoft/Salesforce) that is excellent for many import tasks and has a user-friendly interface. Its free version, however, has a limit of 10,000 records per job. While 300 accounts and their contacts might fall under this limit, Data Loader is the more standard, native, and guaranteed tool for this task within the Salesforce ecosystem without worrying about SaaS limits. The question is best answered by the official, unlimited desktop tool.
C. Manual Import:
This typically refers to using the native "Import" feature for a single object (like Leads or Contacts) under Setup -> Data Import Wizard. It is not feasible for manually importing 300 accounts and their related contacts in one go. This method is GUI-based and better for smaller, simpler imports. D. Data Import Wizard:
This is the correct native tool for simple data imports, but it has significant limitations. It can only import up to 50,000 records for most objects. More importantly, while it can import accounts and contacts and create relationships between them in a single wizard, it is less robust and flexible than Data Loader for complex data mapping and handling errors in very large datasets. For a bulk operation of this size, Data Loader is the administrator's preferred and more powerful tool.

Reference:
Salesforce Help: "Choose a Data Import Tool"
This official article compares all data import tools. It states that the Data Loader is for "Large data volumes" (up to 5 million records) and is the tool to use when you need to "import data for more than one object." The Data Import Wizard is recommended for "Simple data imports" of up to 50,000 records.

Explanation:

To set up the folder hierarchy and access controls effectively, the administrator must utilize folder sharing rules:

B. Share the Helpdesk folder with Support Agents with View access. This fulfills the requirement that Support Agents can run (view) the Helpdesk reports, but nothing more.
C. Share the Support Reports folder with Support Managers with Edit Access. By giving the managers Edit access at the top-level "Support Reports" folder, they automatically inherit "Edit" access to all subfolders beneath it ("Helpdesk" and "R&D"). This fulfills the requirement that they can view and edit all reports in the structure.

Why other options are incorrect:
A. Share the R&D folder with Support Managers with Edit Access. This is redundant if Option C is chosen, as managers already inherit access from the parent folder. Furthermore, sharing only this subfolder doesn't grant them edit access to the Helpdesk subfolder.
D. Share the Support Reports folder with Support Agents with View Access. This would grant Support Agents "View" access to all subfolders, including the "R&D" reports, which violates the requirement that they should not be able to view R&D reports. Access must be granted at the lower "Helpdesk" level instead.

Explanation:

A. The username is already in use another organization ✅
Correct. Salesforce enforces global uniqueness of usernames.
Example: if someone already used john.doe@company.com in another Salesforce org, you cannot reuse it here.

B. The username is restricted to a domain specific to my domain ❌
Not true. Usernames are not restricted to domains — they just need to look like an email address.

C. The email address used for the username has a contact record ❌
Having the same email as a contact record does not prevent user creation. Email ≠ Username restriction.

D. The email used for the username is not a corporate email address ❌
Salesforce does not require usernames to be corporate emails. They only need to be unique and email-formatted.

🔗 Reference
Salesforce Docs: Username and Login Considerations

⚡ Exam Tip:
If the question is about user creation failing, 99% of the time it’s because of username uniqueness.

Explanation:

When creating a validation rule in Salesforce, administrators define rules to enforce data quality by ensuring records meet specific criteria before they can be saved. The following two functions are key components of this process:

B. Error condition formula: This is the core of a validation rule, where the administrator defines a formula that evaluates to true when the record violates the rule. If the formula is true, Salesforce prevents the record from being saved and displays an error message. For example, a formula like CloseDate < TODAY() ensures that an Opportunity’s close date is not in the past. This is a required component of every validation rule.
C. Error message location: This specifies where the error message appears when the validation rule is triggered. Administrators can choose to display the error message at the top of the page or next to the specific field associated with the rule (if a field is referenced in the formula). This ensures users understand why the record cannot be saved and what needs to be corrected.

Why not the other options?
A. Formula return type: This is not a function or component of a validation rule. Validation rules always use a formula that returns a boolean (true/false) to determine if the rule is violated. There’s no option to set a “return type” as you would in a formula field, where return types like Text, Number, or Date are specified.
D. Rule active date: Validation rules in Salesforce do not have a native “active date” setting. While rules can be activated or deactivated (via the “Active” checkbox), there’s no functionality to schedule them for specific dates. Any time-based logic would need to be built into the error condition formula (e.g., using TODAY() or date comparisons).

Key Considerations:
For Northern Trail Outfitters, the administrator should ensure the validation rule aligns with business requirements, such as enforcing data consistency for fields like Account Name or Contact details.
The error message should be clear and user-friendly to guide users (e.g., “Close Date cannot be in the past.”).
Test the validation rule in a sandbox to confirm it works as expected without disrupting existing processes.

Reference:
Salesforce Help: Create Validation Rules
Salesforce Help: Validation Rule Considerations

Explanation

A formula field is the most efficient and accurate way to automatically calculate and display the warranty expiration date based on a different date field.

The administrator can create a custom date formula field on the Installation object.
The formula would reference the Installation Date field (or Warranty Purchased Date if a separate field exists) and automatically add 365 days (or use a function like ADDMONTHS(date_field, 12)).

This ensures consistency, prevents data entry errors, and automatically handles the calculation for both standard 1-year warranties and extended warranties (provided the input date field reflects the actual start date).

Why other options are incorrect
A. Use a formula as the default value of the warranty Expiration Date field: Formula fields calculate values dynamically and display them; they do not serve as a default value for a data entry field that a user can later edit. A default value can only be a static date or another simple formula, but the user could potentially overwrite it incorrectly.

C. Add a validation rule to ensure the Expiration Date field is populated: A validation rule ensures a field isn't blank, but it does not automate the calculation of the date itself. This would still require the installer to manually calculate and enter the correct date, which is prone to errors.

D. Include the warranty Expiration Date field on the mobile page layout: This makes the field visible to the installer on the mobile app, but it does not automate the calculation. The installer would still have to manually input the date, which is inefficient and a source of potential errors. The best approach is to automate the calculation with a formula field that is read-only on the layout.

Explanation:

The requirement is to search for existing records that meet specific criteria and then store values from those records for later use. This describes the exact functionality of the Get Records element.
Get Records: This element is used to retrieve one or more records from the database based on conditions you define (e.g., "Find all Account records where BillingState is 'California'"). Once the records are retrieved, you can access their field values and store them in variables for use in subsequent elements within the Flow.

Why the Other Options Are Incorrect:
A. Assignment: An Assignment element is used to set or change the value of a variable or a field on a record. It does not search or retrieve any data from the database. You would use an Assignment after a Get Records element to store the retrieved values into variables.
C. Create Records: This element is used to make new records in the database. It does not search for or retrieve existing records.
D. Update Records: This element is used to modify the values of existing records. While it works with existing data, its purpose is to write changes, not to search for records and read their values into variables for later logic.

Reference:
Salesforce Help: Get Records Element in Flow
The documentation states: "Use the Get Records element to retrieve records from Salesforce that meet the filter criteria you specify. For example, get all open opportunities for a particular account." This directly matches the requirement to search and store values.

Explanation:

To prevent users from selecting more than one style, the administrator needs to change the field type from a multi-select picklist to a standard picklist.
D. Change the field type from a multi-select picklist field to a picklist field: This is the essential step. Changing the field type will enforce the new rule that only a single value can be selected from the list. Salesforce's picklist field type is designed for single-value selections.
C. Back-up the Shoe Style values in existing records: This is a critical prerequisite. When you convert a multi-select picklist to a picklist, Salesforce will delete any existing data in the field that contains more than one value. To avoid data loss and preserve historical information, the administrator should first back up the data. This can be done using tools like Data Loader or by running a report.

Why the other options are incorrect:
A. Reactivate the appropriate Shoe Style values after the field type changes: This step is not necessary. The values in the picklist will remain available after the field type is changed.
B. Select the “Choose only one value“ checkbox on the pick list field: This checkbox does not exist. The ability to choose only one value is an inherent characteristic of the standard picklist field type, which is what the administrator is changing to.