Salesforce-Platform-Administrator Practice Test Questions

Explanation:

A. Currency Locale
Configuring the Currency Locale is a core Company Setting that controls how currency values are formatted across the org—things like the currency symbol (€, $, £), decimal and thousands separators, and placement of the symbol relative to the number. This is especially important for a global user base because it ensures monetary amounts display consistently and in a way that aligns with the company’s preferred formatting. If your org does not use Multiple Currencies, the Currency Locale effectively dictates the single currency format used throughout Salesforce; if Multiple Currencies is enabled, you’ll still choose a Corporate Currency, but the locale setting remains a Company-level preference for formatting. Making this change at the Company Settings level provides a unified experience without requiring per-user tweaks.

B. Default Language
Default Language is also part of Company Settings and determines the baseline language for UI labels, standard text, and setup menus across the org. While individual users can select their personal language preference, setting the Company’s Default Language creates a consistent foundation for new users and serves as a fallback when a user-specific choice isn’t set or when certain translations aren’t available. For global teams, choosing an organization-wide default (often English) and then allowing user overrides is the standard best practice—ensuring onboarding is straightforward while still accommodating regional needs.

Why the others are not correct

C. Password Policy (Not a Company Setting)
Password Policies are configured under Security and govern authentication requirements (length, complexity, expiration, lockout thresholds). Although they’re typically org-wide (with optional profile-level overrides), they are not part of the Company Settings area that deals with language/locale/fiscal year/business hours. They’re security controls rather than company identity or localization settings. So while crucial for a global team, they don’t answer a question specifically about “Company Settings.”
D. Login Hours (Not a Company Setting)
Login Hours are configured on Profiles, not at the Company Settings level. They restrict when users assigned to a profile may log in (for example, 8:00–18:00 in a given time zone). Because this is profile-based, it’s considered a security/Access configuration rather than a global Company Setting. For a global team with varied time zones, company-level configuration doesn’t apply here; you’d set appropriate windows per profile (or avoid using them if they would block legitimate off-hours access).

Practical admin tip:
For global org readiness under Company Settings, focus on Default Language, Locale, Time Zone, Currency Locale, Fiscal Year, Business Hours, and Holidays. Use profiles/permission sets for access controls like Login Hours and keep Password Policies under Security to meet compliance without conflating them with Company Settings.

Explanation:

When an administrator can perform an action (saving the Opportunity) but a standard user (the VP of Sales) cannot, the issue is almost always related to user-specific security or access restrictions. These restrictions can include:

Profile/Permission Set: The user's profile may lack Field-Level Security (FLS) permission to edit a specific field required for the save (e.g., a hidden validation rule-dependent field).
Sharing Model: The user may lack record-level access (Read/Edit permission) to the specific Opportunity record, the parent Account, or a related record being updated by automation.
Validation Rules/Automation: A validation rule or automation (Flow/Trigger) may contain logic that excludes administrators (e.g., NOT($Profile.Name = 'System Administrator')) but applies to the VP's profile, causing the error only for them.

By logging in as the user (assuming the user has granted login access), the administrator experiences the exact same profile, sharing, and automation restrictions, allowing them to replicate the error and read the exact error message the user is receiving. Once the error is replicated, the administrator can enable Debug Logs for that user to capture the transaction details and pinpoint the exact failing automation or rule.

❌ Incorrect Answers Detail

A. Edit the page layout.
Editing the page layout controls the visual arrangement of fields. While different profiles can see different layouts, the layout itself rarely causes a save error unless a field required by a validation rule is completely removed (which would affect the admin too). It does not validate the user's experience.
B. View the setup audit trail.
The Setup Audit Trail tracks administrative changes to the Salesforce configuration (e.g., who created a field, who activated a flow). It will not show real-time, user-generated errors or failed record transactions.
D. Review the sharing model
Reviewing the sharing model (OWD, Sharing Rules, Role Hierarchy) is a necessary diagnostic step after replicating the error, but it is not the method for validating (replicating) the user's error message itself. The fastest way to validate the error is to experience it firsthand.

Explanation:

A record-triggered Flow is the right solution because it can run automatically when an Opportunity is updated to Closed Won and then find and update related records—in this case, all other open Opportunities on the same Account—to Closed Lost. Build an after-save record-triggered flow on Opportunity with entry criteria like ISCHANGED(StageName) = TRUE and StageName = "Closed Won". In the flow, use Get Records (or a fast lookup) to retrieve all sibling Opportunities where AccountId = $Record.AccountId and Id != $Record.Id and IsClosed = FALSE. Loop through that collection (or use Update Records on a collection without a loop if you prefer) to set StageName = "Closed Lost" (and, if required by your process, a Loss Reason value), then perform a single bulk update. This approach is fully declarative, respects FLS, handles bulk operations (e.g., multiple opportunities closed by data load), and keeps all changes in one transaction so they either succeed together or roll back together. Add guardrails such as checking for primary opportunity flags or record types if only certain deals should force-close their siblings, and consider enabling “Run Asynchronously” (via a scheduled path or an async path) if you anticipate very large sibling sets to reduce save-time latency.

Why the others are not correct

A. Quick Action
Quick Actions require a user to click something and act on a single record. They don’t automatically trigger when an Opportunity is closed won, nor do they naturally update other related records in the background. You’d still need automation (like Flow) behind the scenes to cascade the change.

B. Workflow Rule
Workflow Rules (legacy) can’t mass update related records like sibling Opportunities; they primarily update the same record or send emails/outbound messages. Even with field updates, you can’t iterate other Opportunities on the account and set them to Closed Lost. Salesforce also recommends Flow over Workflow for new automation.

D. Outbound Message
Outbound Messages send data to external endpoints (SOAP) and do not update Salesforce records by themselves. They’re for integration, not for enforcing internal cross-record business rules like closing sibling Opportunities.

Practical admin tip:
Use an after-save flow to avoid recursion issues when you’re updating other records and to ensure the triggering Opportunity’s state is final. Add criteria to skip updates if the sibling is already closed, and include meaningful loss reason defaults so reports remain consistent.

Explanation:

Email-to-Case automatically creates Cases from incoming customer emails sent to designated routing addresses (e.g., support@company.com). To route these Cases to the correct queue (e.g., based on subject keywords, sender domain, or priority):
In Email-to-Case settings (Setup > Service > Email-to-Case):
Create multiple Routing Addresses (each with a unique email).
For each address, specify a Queue as the default owner.
Optionally, enable Assignment Rules integration: Link to active Case Assignment Rules for dynamic routing (e.g., criteria like "Subject contains 'Billing'" → Queue: Billing Support).
Emails to a specific address auto-create Cases owned by its queue—no extra automation needed for basic routing.
This is built-in, declarative, and ensures immediate queue assignment on creation.

Why Not the Others?

A. Utilize a flow to identify the correct queue and assign the case:
Possible (Record-Triggered Flow on Case create to update OwnerId), but unnecessary overhead. Email-to-Case handles routing natively; Flows add complexity for post-creation updates.
B. Use a custom email services to set the owner of the case upon creation:
Custom Email Services (Apex-based) process inbound emails for custom logic/objects. Overkill and code-required; standard Email-to-Case is no-code and queue-focused.
C. Create an Escalation Rules to send cases to the correct queue:
Escalation Rules monitor open Cases for SLA breaches and reassign/notify—not for initial routing on email receipt.

Step-by-Step Setup:
Enable Email-to-Case: Setup > Email-to-Case > Enable (Premium/On-Demand versions).
Create Queues: Setup > Queues > New (add Cases as supported object).
Add Routing Addresses: Setup > Email-to-Case > Routing Addresses > New.
Enter email, select Queue, verify address.
Optional: Activate Case Assignment Rules for criteria-based routing within a queue/address.
Test: Send email to routing address > Verify Case in queue's list view.

References:
Salesforce Help: Set Up Email-to-Case (routing and queues).
Trailhead: Service Cloud Basics (Email-to-Case automation).

For the SP25 exam, note:
Use verified domains for routing emails. Premium Email-to-Case adds threading/auto-responses. Combine with Auto-Response Rules for acknowledgments. For advanced routing (e.g., Entitlements), layer Assignment Rules.

Explanation:

Cloud Kicks needs a self-service way for customers to submit Cases directly from the public homepage without logging in. Web-to-Case generates an HTML form (via Setup > Web-to-Case > Generate) that captures details (e.g., Subject, Description, Contact info) and auto-creates Cases in Salesforce.
Embed the form code on the homepage (e.g., in a web page or Experience Cloud site).
Customize fields, add CAPTCHA for spam prevention, and set default values (e.g., Origin = Web).
Route via Assignment Rules to queues/owners; trigger Auto-Response emails for confirmation.
Supports up to 5,000 Cases/day (standard limit); no licenses needed for customers.

This is no-code, public-facing, and ideal for external submission.

Why Not the Others?
A. SMSResponse: Not a feature. SMS-to-Case exists in some contexts, but not for web forms.
C. Email-to-Case: Customers email a routing address; Cases create from inbox. No web form—requires email client, not homepage integration.
D. Omni-Channel: Routes work (chat, cases) to agents post-creation. Not for customer submission.

References:
Salesforce Help: Set Up Web-to-Case.
Trailhead: Service Cloud Basics (self-service channels).

For SP25 exam, note:
Web-to-Case uses verified domains; combine with reCAPTCHA v2. For branded portals, use Experience Cloud Sites with Case object. Test form submission in sandbox.

Explanation:

The requirement is to display a screen flow for the sales team to add new leads. There are multiple standard ways to launch a screen flow in the Lightning Experience.

Let's evaluate the options:

A. Create a tab and add the screen flow to the page. This is a correct method. An administrator can create a custom Lightning tab of type "Flow." This provides a dedicated tab in the navigation bar that, when clicked, launches the flow in its own window. This is a clean and simple way to give users direct access to the flow.
B. Use a flow element and add the screen flow to the record page. This is another correct and highly contextual method. The administrator can use the Lightning App Builder to add the "Flow" component to any Lightning record page (like the Home page or an App page). This embeds the flow directly on the page, making it easily accessible without needing a separate tab.

Why the other options are incorrect:

C. Add the flow in the utility bar of the console. This is a specific feature for Service Cloud Console applications. Since the scenario involves the sales team adding leads, and does not mention a console app, this is not the standard or intended method for a general sales team.
D. Install an app from the AppExchange. This is completely unrelated. The AppExchange is for third-party applications. The flow has already been built internally; no external app is needed to display it.

Reference:
Salesforce Help: "Add a Flow to a Lightning Page"
Salesforce Help: "Create a Custom Lightning Tab for a Flow"

Explanation:

✅ Correct Answer: C. Create three record types, each with 2 page layouts
Universal Containers has:
Three separate lines of business → each needs its own Record Type
Two user groups (Sales and Service) → each needs a different Page Layout per Record Type
This means:
3 Record Types (one for each line of business)
2 Page Layouts per Record Type (one for Sales, one for Service)
Total: 6 Page Layouts
This configuration allows the administrator to:
Show business-specific fields using Record Types
Tailor user-specific layouts using Page Layouts assigned via Profiles

❌ Why the other options are incorrect:

A. Create two record types, each with 3 page layouts
This only covers 2 lines of business, not all 3. It also assumes 3 layouts per type, which doesn’t align with the 2 user groups.
B. Create one record type with six page layouts
One record type cannot differentiate between three distinct business processes. Record Types are essential for controlling picklists, layouts, and logic per business line.
D. Create six record types, each with 1 page layout
This overcomplicates the setup. You’d need to create redundant record types just to handle layout differences, which is inefficient and harder to maintain.

References:
Record Types Overview – Salesforce Help
Customize Page Layouts – Salesforce Help
Trailhead: Customize Record Types and Page Layouts

Explanation:

A validation rule is the appropriate declarative tool to enforce data quality and business requirements automatically when a user attempts to save a record.

D. Create a validation rule that ensures Showing Date contains a date within the current year.
A validation rule can use a formula to compare the entered Showing Date with the current year using functions like YEAR(TODAY()) and YEAR(Showing_Date__c). The rule would fire (displaying an error message) if the year entered is not the current year, thereby preventing the record from being saved incorrectly.

A. Sync the users' Showing Calendar to Salesforce and filter it to only look at this year.
This is a usability/viewing preference and doesn't prevent invalid data entry into the core database field.

B. Create a report that shows any Showing Dates not scheduled in the current year to the updated.
Reports are reactive tools used for data analysis and cleanup after the fact. They do not proactively prevent bad data from being saved.

C. Add Help Text so the user knows to only add a Showing Date within the current year.
Help text is a good guidance tool, but it relies on the user reading and following instructions. It does not enforce the rule (users can still enter an incorrect date).

Explanation:

Flows in Salesforce must be activated to run and perform actions like creating records. An inactive flow (saved but not activated) won't execute, even if triggered correctly via a button, Quick Action, Process Builder, or record update. This is a common oversight—saving creates a version, but only the active version processes interviews and DML operations (e.g., Create Records element).
Check/fix: In Flow Builder > Open the flow > Click "Activate" (or "Save As" new version and activate).
Production flows can have multiple versions; only one is active at a time.
Debug: Run in Flow Builder Debug mode (simulates execution); check Setup > Flows > Paused & Failed Flow Interviews for errors.

Why Not the Others?

A. The flow is read only: Incorrect.
Flows aren't "read only"—this might confuse with object permissions or sharing, but flows have versions (editable until activated). Read-only access (via permissions) prevents editing, not execution.
C. The flow URL is deactivated: Incorrect.
Autolaunched/Screen Flows don't rely on "URLs" for triggers (unlike classic Visualforce). URLs are for manual runs (e.g., /flow/MyFlow); deactivation isn't a feature—invalid URLs just error.
D. The flow trigger is missing: Partially misleading.
For Record-Triggered Flows, missing entry conditions or trigger settings (e.g., no "When" create/update) could skip runs. But the question implies a general flow (likely Screen/Autolaunched for record creation). Even with a trigger, inactive flows never fire.

References:
Salesforce Help: Activate or Deactivate a Flow.
Trailhead: Flow Builder Basics (activation and versioning).

Explanation:

B. Flow Builder (Screen Flow for guided submission)
To simplify how users submit expense reports, the best front-end, no-code tool is a Screen Flow built in Flow Builder. A screen flow lets you guide users step-by-step through required inputs (dates, categories, amounts, receipts), apply conditional visibility to show only relevant fields (e.g., show “Mileage” fields when Type = Travel), and perform inline validations before save. You can also prefill user/context data (current user, default cost center), calculate totals or policy thresholds with Assignment and Formula elements, and then create or update the Expense Report record and its related lines in one seamless experience. Because it runs right in Lightning (record page, app page, utility bar, or quick action), a screen flow dramatically reduces errors and back-and-forth, ensuring submissions are complete and policy-compliant at the point of entry.

C. Approval Process (routing and authorization)
Once the expense report is created, an Approval Process is the standard Salesforce mechanism to route the record to the correct approvers (e.g., manager → finance → director, or dynamic approvers based on amount, department, or policy). Approval steps can send notifications, lock the record during review, and run entry, approval, and final actions—such as stamping an approved status, updating a reimbursement date, or notifying AP. This provides a consistent, auditable workflow that satisfies the “routing and authorizations” requirement with minimal maintenance and without custom code.

Why the others are not correct

A. Validation Rule
Validation rules are excellent for enforcing field-level constraints (e.g., “Amount must be > 0” or “Receipt required when Amount ≥ 100”), but they don’t provide a guided UI, nor do they perform routing or authorization. They are complementary to a flow (you may still use them to enforce key policies), yet they cannot, by themselves, deliver the end-to-end submission and approval experience the business is requesting.

D. Quick Action
A Quick Action can provide a launch point (e.g., a button) and simple create/update forms, but it lacks the depth of multi-step guidance, conditional logic, calculations, and record orchestration that a Screen Flow offers. You can certainly use a Quick Action to launch the screen flow, but the action alone won’t handle the guided process or the multi-level authorization—those are delivered by Flow Builder and the Approval Process, respectively.

Practical admin pattern:
Build a Screen Flow for data capture (with conditional visibility and calculations), save the Expense Report, and then submit for approval automatically from the flow (or expose a “Submit” action that kicks off the Approval Process). Add targeted Validation Rules only for universal guardrails, not as the primary workflow engine.