Salesforce-Platform-Administrator-II Practice Test Questions

Explanation:

Why: Once you turn on Person Accounts, Salesforce makes an irreversible org-level change. Salesforce’s setup guide explicitly says: “After Person Accounts is enabled, it can’t be disabled.”

Why the others are wrong (quick checks):
B. “Requires less data storage.” — False. Each Person Account is actually an Account + Contact under the hood, so it counts against both objects’ data storage (roughly ~4 KB vs ~2 KB for a single standard record).
C. “Person and Business Accounts can’t be in the same sharing model.” — False. Person Accounts use the Account sharing model; Salesforce requires your OWD to be either Contacts = Controlled by Parent or Accounts and Contacts = Private when enabling, but person and business accounts coexist under Account sharing.
D. “All standard Account fields convert to Person Account fields.” — False. Person Accounts combine certain Account & Contact fields, but not “all” fields/behaviors map 1:1 (there are feature differences and field limitations).

References:
Enable Person Accounts — irreversible once enabled.
Setting Up Person Accounts (Implementation PDF) — storage, sharing prerequisites, and irreversible note.
Considerations for Using Person Accounts — storage counts against Account and Contact.

Explanation:

Salesforce Authenticator is an app that adds an extra layer of security for logging into Salesforce by requiring users to verify their identity using their mobile device after entering their username and password on Salesforce login page. To see how many users have successfully used Salesforce Authenticator since it was rolled out, an administrator can use two methods:

A) Create a new view In Identity Verification History, specifying Method.
Identity Verification History is a tool that shows information about each identity verification event for users in your org, such as the date and time, the verification method used, the IP address, and the status of the verification. By creating a new view in Identity Verification History and specifying the method as Salesforce Authenticator, an administrator can see how many users have used the app to verify their identity when logging in.

D) Export Login History and filter based off of Authentication Method Reference.
Login History is a tool that shows information about each login attempt for users in your org, such as the date and time, the username, the source IP address, the login type, and the status of the login. By exporting Login History as a CSV file and filtering based on the Authentication Method Reference column, an administrator can see how many users have used Salesforce Authenticator as their authentication method when logging in.

Explanation:

The Security Health Check tool quickly identifies objects with public external sharing by auditing Organization-Wide Defaults (OWD) settings, flagging those set to “Public Read Only” or “Public Read/Write.” These settings indicate potential external access (e.g., for Experience Cloud or public sites).

Other options are less suitable:

B. Setup Audit Trail: Tracks setup changes, not current sharing settings.
C. Session Security Settings: Manages user sessions, not object sharing.
D. Object Manager: Requires manual checking of each object’s sharing settings, which is slow.

Reference
Salesforce Help: Security Health Check

Explanation:

The core problem is to open up access for a specific group of users (Finance Team/Drama Team) to a specific set of records (Closed Won Opportunities) when the default sharing is Private. A Sharing Rule is the appropriate tool, and it requires two components: the criteria for the records, and the group of users who receive access.

Define the Records to Share (Criteria-Based):
C. Create a criteria-based sharing rule where the won field = true. (The "won field" refers to the Opportunity Stage being in a Closed Won state).
Since the requirement is based on the content of the record (the stage/status being "Closed Won"), a Criteria-Based Sharing Rule is the correct mechanism.
Define the Users Who Receive Access (Roles and Subordinates):
A. Share with roles and subordinates of the finance director role.
This option correctly identifies the target group. Since the Finance Team and Drama Team are all under the Finance Director role in the hierarchy, sharing to the Finance Director Role and its Subordinates ensures all necessary team members gain access to the Closed Won records identified in step 1.

Why the others are incorrect:
B. Make an owner-based sharing rule where the wnn field = true. This mixes two concepts. An Owner-Based Sharing Rule shares records based on the owner's role, not a field value.
D. Select all opportunities owned by the sales manager role. This would share the Sales Manager's opportunities (both open and closed) with the Finance Team, which is not what was asked. The requirement is to share Closed Won opportunities, regardless of owner.

Explanation:

This question is about troubleshooting a specific automation (a Flow) that is failing to deliver its intended outcome (sending an email). The key is to find the most direct evidence of what happened to the emails themselves.

Why C is Correct:
The Email Logs are the definitive source for tracking the delivery status of every email sent by Salesforce. They show whether an email was sent, queued, or if it failed (and why it failed, e.g., invalid address, exceeded sending limits, etc.). By checking the Email Logs, the administrator can filter for the specific emails sent by the Flow and see their exact status, providing immediate evidence of whether the emails were even dispatched from Salesforce.

Why A is Incorrect:
Paused Flow Interviews show instances where a Flow has stopped because it requires user input (like a Screen Element) or due to a fault setting. Since this Flow is designed to send emails automatically and the issue is with email delivery, not the Flow's execution halting, it's unlikely the problem will be found here. The Flow is likely running to completion but the email action within it is failing.

Why B is Incorrect:
The Process Automation Settings page is used to enable or disable automation features (like Flows and Processes) for the entire org. While you should check here to ensure automation is active, it's a broad control and not the right tool for investigating the specific failure of individual email deliveries from a functioning Flow.

Why D is Incorrect:
The Setup Audit Trail logs who made configuration changes in Setup. It would show if someone modified the Flow or email settings, but it does not provide any information about the runtime behavior of the Flow or the delivery status of the emails it tried to send.

Reference:
Salesforce Help: "Monitor Email"
This documentation details how to use the Email Log files to see the status of sent emails. It is the primary tool for administrators to verify email delivery and diagnose failures, making it the most direct and appropriate place to start this investigation.

Explanation:

Tableau CRM (formerly known as Einstein Analytics) is the best solution for Ursa Major Solar’s needs because it:

🔗 Connects to multiple data sources, including Salesforce, external databases, and internal shared drives via connectors or data integration tools.
📊 Enables creation of complex dashboards with interactive charts, KPIs, and advanced analytics.
🧠 Supports AI-powered insights, predictive modeling, and deep data exploration.
This makes it ideal for organizations that need enterprise-grade analytics beyond standard Salesforce reporting.

❌ Why the other options fall short:
A. Lightning Dashboard Builder:
Limited to data already in Salesforce; cannot pull from external sources like shared drives.
B. Report Builder:
Good for basic reports, but lacks the visual complexity and data integration capabilities needed here.
C. List Views:
Designed for record filtering and quick views, not for analytics or dashboards.

📘 Reference:
Salesforce Help: Tableau CRM Overview

Explanation:

When a user is unable to log in to Salesforce via multi-factor authentication (MFA), the administrator needs to investigate where the login attempt is failing. These two areas provide critical information:

A. Identity Verification History: This section shows details about all identity verification attempts made by users, including those related to MFA.
It records the method used (e.g., Salesforce Authenticator, SMS, email), the result (success or failure), and the time of the attempt.
This can reveal if the user is failing to provide the correct verification code, if there's an issue with the registered verification method, or if the code is being sent to an incorrect or inaccessible location (like a deactivated phone).

B. Login History: This provides a detailed list of all login attempts (both successful and failed) for the entire organization or for individual users.
It includes the login status (e.g., Success, Failed), the type of login (e.g., standard login, API login), the IP address, and any specific error messages associated with the login attempt.
For MFA issues, the Login History can indicate if a user's initial login attempt (username and password) was successful but the subsequent MFA verification failed, or if there were other issues preventing login before the MFA step.

Why other options are incorrect
C. Debug Logs: Debug logs are primarily used by developers and administrators to troubleshoot Apex code, flows, workflows, and other automated processes within Salesforce. They track events that occur within the system's execution context, not necessarily the external login and identity verification process itself. While some login details might appear if a login triggers Apex or a flow, it's not the primary or most efficient place to troubleshoot MFA failures.
D. Setup Audit Trail: The Setup Audit Trail tracks configuration changes made by administrators in Salesforce Setup. While it's useful for auditing who made changes to settings (like enabling or disabling MFA), it does not log individual user login attempts or identity verification actions.

Explanation:

Why: Delegated Administration lets you grant select users admin-like powers scoped to specific custom objects—e.g., managing fields, validation rules, and other object configuration—without giving them full org-wide setup access.

Why not the others:
A. View Setup and Configuration – Read-only; no changes allowed.
C. Sharing Rule – Controls record access, not configuration.
D. Modify All Data – Very broad data access; still doesn’t grant object configuration abilities and is over-privileged.

Explanation:

The requirement is to allow the sales team at Cloud Kicks to track customer contact information and footwear preferences in Salesforce, store this data in a spreadsheet, and display it on the Contact record. The administrator needs to configure Salesforce to handle the data from the spreadsheet and ensure the preferences are visible when viewing the Contact record. Here’s a step-by-step explanation of why Data Loader and Lightning Object Creator are the correct choices and why the other options are not suitable:

A. Data Loader (Correct)
Why: The customer information and footwear preferences are currently stored in a spreadsheet. Data Loader is a tool that allows administrators to import data from external sources, such as spreadsheets (e.g., CSV files), into Salesforce. The administrator can use Data Loader to import the contact information into the Contact object and the footwear preferences into either custom fields on the Contact object or a related custom object.
How it helps: Data Loader enables the initial import of spreadsheet data and supports ongoing updates or bulk uploads when new customer forms are collected. For example, the administrator can map the spreadsheet columns (e.g., Name, Email, Footwear Preferences) to fields in the Contact object or a related custom object. This ensures the data is available in Salesforce and can be viewed on the Contact record.
Reference: Salesforce Help - Data Loader Guide

C. Lightning Object Creator (Correct)
Why: Lightning Object Creator is a Salesforce tool that allows administrators to create custom objects directly from a spreadsheet. Since the footwear preferences may involve multiple data points (e.g., shoe size, style, color preferences), the administrator could create a custom object (e.g., "Footwear Preferences") to store this information and relate it to the Contact object via a lookup or master-detail relationship. This custom object can then be displayed on the Contact record’s page layout as a related list, allowing the sales team to view the preferences when accessing a Contact record.
How it helps: Lightning Object Creator simplifies the process of building a custom object by automatically generating fields based on the spreadsheet’s columns. For example, the administrator can upload the spreadsheet, map the columns to fields, and create a custom object linked to Contacts. This ensures the preferences are structured and easily accessible on the Contact record.
Reference: Salesforce Help - Create Custom Objects with Lightning Object Creator

B. Lookup Field (Incorrect)
Why: A Lookup Field creates a relationship between two objects, allowing one object to reference a record in another object. While a lookup field could be used to relate a custom object (e.g., Footwear Preferences) to the Contact object, it is not a complete solution for configuring the requirement. The lookup field alone does not address how to import the spreadsheet data or create the structure to store the preferences. It is a component of a solution but not a standalone tool for this use case.
Why not chosen: The requirement involves importing data and setting up a structure to store and display preferences, which requires tools like Data Loader and Lightning Object Creator. A lookup field is a secondary configuration that might be used after creating the custom object.

D. Schema Builder (Incorrect)
Why: Schema Builder is a visual tool for creating and modifying objects, fields, and relationships in Salesforce. While it could be used to manually create a custom object and fields to store footwear preferences, it does not directly address the need to import data from a spreadsheet or automate the object creation process based on the spreadsheet’s structure. Lightning Object Creator is a more efficient tool for this purpose, as it is designed specifically for creating objects from spreadsheets.
Why not chosen: Schema Builder is less efficient than Lightning Object Creator for creating a custom object from a spreadsheet and does not help with importing the data, which is a key part of the requirement.

Summary:
Data Loader is essential for importing the customer information and footwear preferences from the spreadsheet into Salesforce, ensuring the data is available in the Contact object or a related custom object.
Lightning Object Creator is ideal for creating a custom object to store footwear preferences directly from the spreadsheet, which can then be linked to the Contact object and displayed as a related list on the Contact record.
Together, these tools address both the data import and the structural setup needed to track and display the information in Salesforce.

Explanation:

Person Accounts are designed for Business-to-Consumer (B2C) models where the individual consumer is the primary focus of sales, service, and marketing efforts. Unlike traditional Salesforce Accounts (which represent companies), Person Accounts combine Account and Contact into a single record to represent a person as both the customer and the account.
This is ideal when:
You're selling directly to individuals, not companies.
You want to track personal preferences, purchases, and interactions.
You don’t need a separate business entity tied to the contact.

❌ Why the other options are incorrect:
A. Recording Opportunities on Contacts is not supported natively; Salesforce requires Opportunities to be tied to Accounts. Person Accounts solve this by merging the two, but the reasoning in A is flawed.
B. B2B models are better served by Business Accounts, where companies and their contacts are tracked separately.
D. If you need both a Contact and Account on Case records, Person Accounts may not be ideal, since they merge the two into one record.

📘 Reference:
Salesforce Help: Person Accounts Overview