Free Salesforce-Platform-Administrator Practice Test Questions 2026

Explanation:

A. Add a custom master-detail field for shoe designs on the Product object
To establish the one-to-many relationship, the admin adds a Master-Detail (Shoe Design) field on the Product object. This field is placed on the child object (Shoe Design) during creation, but the question phrasing reflects common exam language where the field appears on the parent in layout context.
Master-detail enforces strong referential integrity:
Multiple designs per product are supported natively.
Deletion protection: Child records (designs) are automatically deleted if the parent Product is deleted (cascade delete), and users cannot delete a design if it violates business rules (e.g., via validation). More importantly, master-detail prevents orphan records and supports roll-up summary fields on Product (e.g., Count of Designs, Sum of Estimated Cost, Filter by Stage = "Approved").
Security: Child records inherit sharing from the parent, simplifying access control.
This relationship fully satisfies the need for tracking across stages and preventing unintended deletion through governed data architecture.

B. Create a custom object for shoe designs
Cloud Kicks requires a dedicated structure to capture and manage shoe designs independently of the standard Product (Product2) object. Salesforce provides no standard object tailored for tracking design versions, stages (e.g., Concept, Prototype, Final), or associated assets (e.g., sketches, materials). By creating a custom object named Shoe Design, the admin can define custom fields such as Design Name, Stage (picklist), Designer (lookup to User), Design Date, and Status, ensuring full flexibility. This object becomes the child in a parent-child relationship, enabling one Product to have many designs—exactly matching the "multiple designs for one product" requirement.

Why the Other Options Are Incorrect:

C. Use the standard object for designs
Salesforce includes standard objects like Product2, PricebookEntry, Asset, and Opportunity Product, but none are designed for tracking iterative design versions with custom stages. Product2 is meant for catalog items (e.g., "Nike Air Max"), not design drafts. There is no native "Design" object. Using a standard object would require misusing fields (e.g., stuffing design stage into Description) and offers zero support for relationships, roll-ups, or deletion control. This option fails both functionality and data integrity requirements.

D. Configure a custom lookup field for shoe designs on the Product object
A lookup relationship creates a loose link between Product and a custom Shoe Design object.
While it allows multiple designs per product, it falls short in critical ways:
No deletion protection: Users can delete a Shoe Design record even if it’s actively referenced, creating orphans.
No roll-up summaries: Product cannot automatically count or aggregate design data (e.g., "How many designs in 'Review' stage?").
Weaker security: Sharing is not inherited; manual sharing rules are needed.
No cascade delete: Deleting a Product leaves design records dangling.
While lookup is simpler, it does not meet the governance and reporting needs implied by stage tracking and deletion prevention—master-detail is required for a robust solution.

Reference:
Salesforce Help: Create a Master-Detail Relationship
Trailhead: Data Modeling → Build a One-to-Many Relationship with Master-Detail

Exam Tip:
Multiple child records + roll-up summaries + deletion control? → Choose Master-Detail (field on child).
Loose relationship, optional parent? → Use Lookup.
"Standard object for X" with no native fit? → Always requires a custom object.

Explanation:

Using Lightning App Builder, an admin can make a Case page truly dynamic by applying Component Visibility filters (and, if desired, record field filters and audience-based rules). This lets you show or hide entire components—like related lists, quick action panels, dashboards, or rich text instructions—based on who the user is (Role, Profile, or Permission Set), what they can do (permission-based), and the case’s context (field values such as Priority, Status, Record Type, or Product). The result is a page that automatically adapts so each role sees only the most relevant information and tools, reducing clutter and clicks while improving task focus and speed.

Why not the others:

B — Remove fields from the record details component:
This is a static, global change that impacts all users equally. It doesn’t tailor the experience by role or case context, so you either hide fields some users still need or keep fields that remain noise for others.

C — Delete the extra component from the page:
Deleting components is a blunt instrument and permanently reduces functionality for everyone. It fails the requirement of making pages dynamic for different roles; it just removes options for all users.

D — Include more tab components with filters:
Adding more tabs typically adds complexity and extra clicks. While tabs can organize content, they don’t inherently provide conditional visibility per role or per case state. You can still end up with crowded pages and users digging through tabs that aren’t relevant to them. Component Visibility directly solves the personalization need with less clutter.

Explanation:

✅ Why this is correct:
A Validation Rule is the proper way to enforce that users enter a Loss Reason when an Opportunity’s Stage = Closed Lost.
This rule ensures the record cannot be saved unless the required field is filled in, but only under the specific condition (Closed Lost).
For example:
AND(
ISPICKVAL(StageName, "Closed Lost"),
ISBLANK(Loss_Reason__c)
)

This formula triggers an error message like "Please enter a Loss Reason before closing this Opportunity as Lost."
It allows the field to remain optional for all other stages.
The administrator can place the error message either at the top of the page or under the Loss Reason field.
It’s flexible, maintainable, and applies only when the specific criteria are met.

❌ Why not the others:

A. Select the Required checkbox next to the Loss Reason field on the page layout.
That only makes the field required for the layout, meaning it’s always required, no matter what the Opportunity Stage is. It can’t enforce “required only when Closed Lost.” The user couldn’t save any Opportunity record without filling Loss Reason, even in early stages.

C. Check the Required checkbox on the Loss Reason field in Object Manager.
This makes the field universally required across all contexts—including imports, automation, and integrations—not just when Closed Lost. It lacks the conditional logic you need.

D. Configure a Workflow Rule to display an error if Loss Reason is blank.
Workflow Rules cannot display errors or stop record saves. They can only perform post-save actions (like field updates, emails, or tasks). They don’t validate data before saving—so this cannot enforce a user-entered field requirement.

✅ In summary:
To enforce conditional data entry (“Loss Reason required only when Closed Lost”), use a Validation Rule—the only Salesforce automation that can block a save and show an inline error under the right condition.

Explanation:

The Setup Audit Trail is the administrator’s go-to tool for reviewing recent configuration changes made in the org. It tracks changes such as:

Creation or modification of fields, objects, page layouts
Changes to profiles, permission sets, and workflow rules
Updates to automation tools like Flows and Process Builder

Administrators can view up to 180 days of setup changes, including who made the change, what was changed, and when — making it ideal for auditing and troubleshooting configuration issues.

❌ A. Critical Updates
Critical Updates are Salesforce-pushed changes that affect platform behavior or security. They allow admins to test and activate updates before enforcement, but they do not track admin-made configuration changes.

❌ B. Debug Logs
Debug Logs capture runtime events like Apex execution, workflow processing, and errors during user actions. They’re useful for troubleshooting code and automation, but they do not show configuration changes made in Setup.

❌ D. Field History Tracking
Field History Tracking logs changes to field values on records, not configuration changes. It’s used for auditing data changes (e.g., status updates on Cases or Opportunities), not setup modifications.

Reference:
Salesforce Help: Setup Audit Trail

Explanation:

C. Resetting a locked-out user's password automatically unlocks the user's account:
This is a key administrative consideration. If a user is locked out due to too many failed login attempts, an administrator can both reset their password and simultaneously unlock their account in one action, allowing them to regain access immediately.

D. After resetting a password, the user may be required to activate their device to successfully log in to Salesforce:
When a password is reset (either by the user via "Forgot Password" or by an admin), the user's security token is also reset. Logging in from an unrecognized browser or IP address after a password reset often triggers an identity verification challenge (e.g., email code, authenticator app code) to activate the device, ensuring the new login attempt is secure.

Why other options are incorrect

A. Resetting the password will change the user’s password policy:
Resetting a password does not change the user's assigned password policy (which is defined by their profile or an assigned permission set). The new password must comply with the existing policy.

B. Single sign-on users can reset their own passwords using the forgot password link:
This is generally incorrect. For users configured for Single Sign-On (SSO), their credentials are managed by an external Identity Provider (IdP), not Salesforce. Only a Salesforce administrator can reset the password for an SSO user within Salesforce's local storage (which is typically only used for a direct Salesforce login as a backup); the user cannot use the standard "Forgot Password" link on the Salesforce login page to reset their external credentials.

Explanation:

Why this is correct:
Account Teams let you define a repeatable set of people and roles (e.g., Account Manager, Engineer, Assistant) who collaborate on Accounts. With a Default Account Team, each user can store their standard trio once and add them to any new or existing account with one click—or automatically on ownership change—so those same teammates always get the right access and role labels.

Why not the others:

A. Opportunity Teams with splits focus on opportunities and revenue attribution, not the ongoing collaboration at the account level. This doesn’t solve the “same team per customer account” need.
C. Queues for account ownership aren’t supported; queues are for objects like Leads/Cases, not Accounts. Also, queues don’t model roles or recurring collaboration patterns.
D. Manual sharing is ad-hoc and error-prone. It doesn’t capture roles, and it must be repeated for every account—no “default team” convenience or consistency.

Explanation:

The Employee Engagement Committee needs to post updates to all employees while preventing others from posting—a one-way communication channel. Chatter Broadcast Groups are the only native Chatter group type that enforces admin/poster-only posting with company-wide visibility. Admins configure this in Setup > Chatter Settings > Enable Chatter > Allow Broadcast Groups, then create the group:
Group Type: Select Broadcast.
Membership: Add all employees (via public groups, roles, or “All Internal Users”).
Posters: Restrict to committee members only (via “Managers” or a custom public group).
Result:
Committee posts to everyone.
Regular employees can only read, like, or comment (no new posts).
Updates appear in Chatter feeds org-wide.
This delivers controlled, scalable internal announcements.

Why the Other Options Are Incorrect:

A. Chatter Stream
Chatter Streams are personal custom feeds where individual users manually combine records, groups, or people. They are not group containers, cannot restrict posting, and are user-specific, not org-wide. This fails the broadcast and access control needs.
C. Chatter Recommendations
Chatter Recommendations are AI-suggested people, groups, or files to follow based on activity. They do not create communication channels or control posting rights. This is a discovery feature, not a group.
D. Chatter Unlisted Group
Unlisted Groups are private (hidden from search, invite-only). They allow full member posting unless manually restricted via “Managers can post” setting—but even then, visibility is limited, not org-wide. This contradicts the goal of all employees seeing updates.

Reference:
Salesforce Help: Broadcast Groups
Trailhead: Chatter Basics → Use Broadcast Groups for Announcements

Exam Tip:
One-way company announcements? → Broadcast Group.
Private + full posting? → Unlisted.
Personal feed? → Stream.
AI suggestions? → Recommendations.

Explanation:

The core of the problem is that the company has support reps operating in two different time zones (Pacific and Eastern) who need different coverage windows. Business Hours in Salesforce are used to define when your organization is "open" for operations, which is critical for features like Entitlement Management, Case Escalations, and SLA timers.
Creating one set of business hours per time zone is the standard and correct solution because:
Granular Assignment: You can create a "Pacific Business Hours" set (9 AM - 5 PM PST) and an "Eastern Business Hours" set (9 AM - 5 PM EST, which is 3 hours earlier than PST).
Link to Specific Support Processes: These different business hours can then be assigned to different support channels, entitlement processes, or even specific record types. This allows the Eastern Time reps to operate on a schedule that matches their local working hours, while the Pacific reps remain on their own schedule.

Analysis of Incorrect Options

Why A is Incorrect (Set temporary business hours for each time zone):
Business hours are not meant to be "temporary." They are a foundational setting that defines operational hours. Constantly changing them would be administratively burdensome, error-prone, and would disrupt any processes (like SLAs) that depend on them. A permanent, structured solution is required.

Why B is Incorrect (Adjust the current business hours to accommodate the Eastern Time Zone):
This would create a single, wide window (e.g., 9 AM PST to 8 PM PST) to cover both time zones. This is not what the business needs. The Eastern reps need their coverage to start and end 3 hours earlier, not for the overall support day to be extended. Furthermore, this would force Pacific reps to be on a schedule that doesn't match their local time.

Why D is Incorrect (Allow the reps to set business hours manually):
There is no feature that allows individual reps to set their own business hours. Business Hours are an organization-level or process-level setting controlled by an administrator. This is not a configurable user setting.

Summary & Key Takeaways for the Exam
When different groups in your organization need different operational hours (e.g., by region, department, or product line), the solution is to create multiple sets of Business Hours.
These different Business Hours sets can then be assigned to Entitlement Processes, Holidays, and other support features to ensure timers and escalations run correctly for each specific context.

Reference:
This question tests your knowledge of Service Cloud configuration, specifically the setup and application of Business Hours to model real-world operational schedules.

Explanation:

To make a Screen Flow visible from Case records, the administrator should embed it in the Lightning Record Page for the Case object using the Lightning App Builder.
This allows:

Displaying the flow directly on the Case page
Triggering the flow when reps open a Case
Providing a guided, interactive experience for collecting customer issue details

The Lightning Page is the correct distribution method for placing flows contextually within record pages.

❌ A. Page Layout
Why it’s incorrect: Page Layouts control field arrangement and related lists, but they do not support embedding screen flows. Flows must be added via Lightning Pages, not traditional page layouts.

❌ B. Component Filter
Why it’s incorrect: Component Filters are used to conditionally show or hide components on a Lightning Page. They are not a distribution method themselves — they enhance visibility logic after the flow is placed on the page.

❌ D. Home Page
Why it’s incorrect: The Home Page is a global landing page and not tied to specific records like Cases. Placing the flow here would make it less contextual and harder for reps to use during Case interactions.

Reference:
Salesforce Help: Add a Flow to a Lightning Page

Explanation:

When a managed package ships a Permission Set Group (PSG) that includes powerful object permissions—like Delete—you can’t edit the managed assets directly. Salesforce solves this with Muting Permission Sets, which are attached inside the PSG and allow you to turn off specific permissions that the group would otherwise grant. This gives admins a precise, supportable, and upgrade-safe way to subtract access (e.g., mute “Delete” for Account, Case, or any object) while still keeping all the other granted rights and updates from the managed package intact.

Why not the others:

B — Create a new permission set that has Delete deselected for the objects. Permission sets are additive only; they can grant access but cannot remove access that’s already granted elsewhere. Adding another permission set doesn’t “take away” Delete—once a user has it from the PSG, it stays unless you mute it within that PSG.

C — Create a new role that prevents Delete permissions from rolling up to the users. Roles control record visibility (sharing) and reporting hierarchy, not CRUD. A role can’t remove object-level Delete permission; a user with Delete can still delete any records they can see and have permission to modify.

D — Edit the profile for the users to remove Delete access from the objects. Profiles establish a baseline, but permission sets and groups layer on top. If the PSG grants Delete, removing Delete from the profile won’t counteract it. The effective permission remains granted unless you neutralize it with a muting permission set in the PSG.

Explanation:

The scenario describes an automated flow that is triggered by a process when an account is created. The most efficient and targeted way to troubleshoot a flow is to use its built-in debugging tool.

The Flow Debug feature is designed specifically for this purpose. It allows an administrator to:

Simulate the Trigger: You can start the debug session and choose to simulate the flow's starting conditions (e.g., "when a new Account is created").
Step Through Execution: The debugger runs the flow step-by-step, allowing you to see the exact path the flow takes.
Inspect Variables and Data: At every step, you can see the values of all variables and field values, making it easy to identify where a formula is miscalculating, a decision is taking the wrong path, or a field is not being set as expected.

This provides immediate, granular insight into the flow's logic and data during runtime, which is exactly what's needed to find out why it's "not working properly."

Analysis of Incorrect Options

Why B is Incorrect (Review debug logs with the login level):
Debug Logs are primarily for troubleshooting Apex code. While system-initiated flows (like those launched by a process) can generate debug log entries, this is not the most direct or user-friendly method. It requires setting up a trace flag for the "Automated Process" user, and the logs are very technical and complex to read. The native Flow Debug is a simpler, more visual, and more appropriate tool for a declarative flow.

Why C is Incorrect (View the setup audit Trail and review for):
The Setup Audit Trail logs configuration changes made by administrators in Setup (e.g., who created a new field or modified a profile). It does not log the runtime execution or errors of automation like flows. It would not help you identify why a flow is failing to set field values correctly.

Why D is Incorrect (Setup Email logs and review the send error log):
Email Logs are used to track the delivery status of emails sent from Salesforce. Since the flow's purpose is to set field values on an account and does not involve sending emails, this log would be irrelevant for troubleshooting this specific issue.

Summary & Key Takeaways for the Exam
For troubleshooting Flows, the first and best tool is the built-in Flow Debugger.
Use Debug Logs primarily for Apex code, or for flows only when the debugger is insufficient for complex, multi-user scenarios.
The Setup Audit Trail is for tracking admin configuration changes, not runtime errors.

Reference:
This question tests your knowledge of Process Automation troubleshooting, specifically the tools available to debug Flows. Knowing when and how to use the Flow Debugger is a key skill for a Platform Administrator.

Explanation:

Why this is correct:
Marking the custom field Required at the field-level (universally required) enforces that every Invoice record must have a value—no matter how it’s created: UI, API (from the external billing system), imports, flows, etc. That’s the most reliable way to guarantee completeness for every record source.

Why not the others:
B. Create a Process Builder to set the field. Process Builder is legacy, and even with Flow/Automation you still can’t guarantee a value at insert if the integration doesn’t provide one (the transaction could fail earlier or your automation might not have a correct value). Field-level required is simpler and stricter.

C. Define an approval process for the child. Approval processes don’t enforce field population at creation; they control review/approval, not data-entry requirements.

D. Require the field on the record type. Record types don’t have a “required” setting. You can make fields required on page layouts, but that only enforces in the UI—not via API/integrations. It wouldn’t satisfy the external system use case.

References:
“Create or Edit Fields” → Require this field (universally required fields apply in UI, API, and imports).
“Page Layouts vs. Field-Level Requirements” (page layout required applies only in the UI).