Salesforce-Platform-Administrator Practice Test Questions

Explanation:

Salesforce’s Company Settings define defaults that apply org-wide before individual user overrides. The Default Language setting determines which language appears on labels, system messages, and setup pages for new users until they select their personal language preference. Likewise, the Currency Locale sets the default currency and number-formatting locale for multi-currency orgs, determining how amounts display on records and reports. In contrast, Password Policy and Login Hours belong under Security Settings and Profile configuration, respectively, and are not part of Company Settings. By configuring the Default Language and Currency Locale in Company Settings, the administrator ensures the entire global team sees consistent, localized defaults immediately upon login, before their personal preferences take effect.

Log in as the user

Explanation:

Salesforce’s “Login As” feature lets administrators assume the identity of any standard user (subject to permission settings) to reproduce exactly what the user experiences, including UI configurations, sharing rules, record-level security, and profile restrictions. By logging in as the VP, the administrator can replicate the error message, inspect which field or sharing rule is blocking the save, and see any page-layout or validation-rule messages—without asking the VP to take screenshots or describe the issue. This direct approach is faster and more accurate than reviewing audit trails or sharing models in isolation.

Flow Builder

Explanation:

A record-triggered flow in Flow Builder can listen for the Opportunity’s StageName changing to “Closed Won.” When triggered, the flow can Get Records for all other open Opportunity records linked to the same Account, loop over them, set their StageName to “Closed Lost,” and then Update Records in bulk. This declarative solution handles complex record relationships and bulk data efficiently, with low maintenance. Workflow Rules lack looping constructs or the ability to affect multiple child records, and Quick Actions and Outbound Messages cannot dynamically iterate over a set of related records for update.

Configure Email-to-Case so emails are delivered to the correct queue

Explanation:

With Email-to-Case, you define Routing Addresses that specify which email addresses map to particular Queues or Users. When an email arrives at a routing address, Salesforce automatically creates a case and assigns it to the specified queue. This setup requires no custom code or Flow, and it centrally manages incoming customer emails. Custom Email Services could achieve a similar result but require Apex; Escalation Rules operate after case creation, not at assignment time; and generic Flows would duplicate built-in Email-to-Case functionality.

Web-to-Case

Explanation:

Web-to-Case generates HTML code for a public web form that can be embedded on any external site. When customers fill out and submit the form, Salesforce automatically creates Case records in your org, populating fields like Subject, Description, and Origin. This feature doesn’t require customers to log in or send emails; it simply captures web submissions. Email-to-Case requires email, Omni-Channel routes existing cases, and SMS Response is for text messaging—none of which provide a public web form.

Create a tab and add the screen flow to the page.

use a flow element and add the screen flow to the record page.

Explanation:

Screen flows can be embedded in Tabs (A) or Record Pages (B) via Lightning App Builder. The utility bar (C) is for console apps, and AppExchange (D) is irrelevant.

Explanation:

Record Types let you segment data by business line, and Page Layouts control which fields appear. Since there are three lines of business, you create three record types (one per line). Each record type needs two page layouts—one tailored for sales and one for service users—totaling six page layouts. Users see the layout that matches their profile’s page layout assignment for each record type. This design scales cleanly; alternative configurations (one record type with six layouts or six record types) would misalign semantics and complicate maintenance.

Create a validation rule that ensures Showing Date contains a date within the current year.

Explanation:

A validation rule can reference the Showing_Date__c field and compare it against functions like YEAR(Showing_Date__c) = YEAR(TODAY()). If the date falls outside the current calendar year, the rule triggers an error and prevents record save. Help text, reports, calendar filters, or external syncs do not enforce data integrity at entry time, allowing invalid dates to slip through. A validation rule provides immediate feedback and guaranteed compliance.

Explanation:

Salesforce Flows must be explicitly activated before they run. An inactive flow—even if correctly built and deployed—will not trigger on record operations or manual calls, so no records are created. Read-only flows cannot update data but will surface errors; missing triggers would prevent execution altogether, but standard practice is to confirm activation first. Verifying the flow’s status in Setup and activating it immediately resolves the silent failure.

Flow Builder

Approval Process

Explanation:

A screen flow built in Flow Builder can guide users step-by-step through entering expense details, attach receipts, and review totals. Once the flow creates the Expense Report record, an Approval Process routes the report automatically for manager authorization, enforces entry criteria (e.g., amount limits), and tracks approval history. Validation Rules ensure data quality but don’t handle routing; Quick Actions launch flows but aren’t the end-to-end solution.