Salesforce-Platform-Administrator Practice Test Questions

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.

Explanation:

When converting a Lead in Salesforce, you can map custom fields from the Lead to the resulting Account, Contact, or Opportunity. Here's how this works:
🧩 C. Create a custom field on the Opportunity and map the two fields ✅
You must first create a matching custom field (e.g., Product Category) on the Opportunity object.
Then, go to Setup → Object Manager → Lead → Fields & Relationships → Map Lead Fields
From there, you can map the Lead field to the Opportunity field so the value transfers during conversion.

❌ Why the Other Options Don’t Work:
A. Map the lead custom field to the product's product category field
The Product object is unrelated to Lead conversion.
You can’t map Lead fields to Product fields — they’re not part of the conversion flow.
B. Create a workflow to update Opportunity fields based on the lead
Workflow Rules do not trigger during lead conversion.
You’d need Apex or Flow for post-conversion logic, but field mapping is the simpler and correct approach here.
D. Configure the product categories picklist field on the product
Again, the Product object is not involved in Lead conversion.
This doesn’t help transfer data from Lead to Opportunity.

🔗 Reference:
Salesforce Help: Map Lead Fields
Trailhead Module: Lead and Opportunity Management

Explanation:

Requirement:
When a case is created (via email or web), customers should immediately get an acknowledgement email.
Different emails should be sent depending on case priority (Low vs. Medium vs. High).
Administrator already has three email templates.

Key Concept:
Auto-Response Rules are specifically designed to send initial email notifications to the customer when a case is submitted.
You can have one active auto-response rule per object (e.g., Cases), but that rule can contain multiple rule entries with different criteria and different email templates.

📖 Why Not the Others?
A. Include three assignment rules ❌
Assignment rules determine who owns the case, not what emails go out to customers.
B. Add three auto-response rules ❌
Salesforce only allows one active auto-response rule per object (Case, Lead). You can’t create multiple active rules for Case.
C. Configure one workflow rule ❌
Workflow/email alerts can send notifications, but they’re intended for internal users (like notifying managers or agents).
Customer acknowledgement emails for new cases must come from Auto-Response Rules.
D. One auto-response rule with three entries ✅
Best practice. One Case Auto-Response Rule → Three rule entries (Low, Medium, High priority).
Each rule entry maps to its own email template.

🔗 Reference
Salesforce Docs: Set Up Case Auto-Response Rules

⚡ Exam Tip:
Assignment Rule = case owner.
Auto-Response Rule = customer acknowledgement.
Escalation Rule = time-based reassignment.
Workflow/Process Builder = internal automation/notifications.

Explanation:

To ensure that managers cannot see feedback records submitted by their staff in a custom object at Northern Trail Outfitters, the administrator needs to configure the object's sharing settings to restrict access appropriately. Here’s why the correct answer is:
A. Uncheck grant access using Hierarchies:
By default, Salesforce’s role hierarchy grants access to records for users higher in the hierarchy (e.g., managers) if they have at least read access to the object. For a custom object containing sensitive feedback, unchecking “Grant Access Using Hierarchies” in the object’s Sharing Settings (under Setup > Security > Sharing Settings) ensures that managers cannot access their staff’s feedback records, even if they are above their staff in the role hierarchy. This setting prevents the role hierarchy from automatically sharing records upward, making it the most effective way to meet the requirement.

Why not the other options?
B. Define a criteria-based sharing rule:
Criteria-based sharing rules are used to share records with specific users or groups based on field values (e.g., share records where Department = 'HR'). While this could be used to share feedback records with HR or specific roles, it doesn’t inherently prevent managers from accessing records if they already have access via the role hierarchy. It’s not the best solution for restricting manager access.
C. Set the default external access to private:
“Default External Access” applies to external users (e.g., Experience Cloud or Communities users) and controls access for external sharing models. Since the requirement involves internal employees and managers, this setting is irrelevant. The correct setting to consider would be the Organization-Wide Default (OWD) for internal access, which could be set to Private to limit access to record owners and those explicitly granted access. However, this alone doesn’t address the role hierarchy issue, as managers higher in the hierarchy could still access records unless “Grant Access Using Hierarchies” is unchecked.
D. Configure an owner-based sharing rule:
Owner-based sharing rules share records based on the record owner’s attributes (e.g., role or public group). This could be used to share feedback records with HR or other groups, but it doesn’t prevent managers from seeing records if they have access via the role hierarchy. It’s less effective than disabling hierarchy-based access for this use case.

Recommended Configuration Steps:
Set the OWD to Private: In Setup > Security > Sharing Settings, set the Organization-Wide Default for the custom Feedback object to “Private.” This ensures only the record owner (e.g., the employee submitting feedback) and users with explicit access (e.g., HR admins) can view the records.
Uncheck Grant Access Using Hierarchies: In the same Sharing Settings page, uncheck “Grant Access Using Hierarchies” for the custom Feedback object to prevent managers higher in the role hierarchy from accessing their staff’s feedback records.
Grant Access to HR: Use manual sharing, sharing rules, or profiles/permissions to grant access to HR team members or specific roles who need to view the feedback records.
Consider Field-Level Security: Hide sensitive fields (e.g., feedback comments) from profiles assigned to managers to add an extra layer of security.

Key Considerations:
Ensure the custom object has fields to capture feedback (e.g., Manager Name, Feedback Text) and that employees have create/edit permissions via their profile or permission sets.
Test the configuration in a sandbox to confirm managers cannot access feedback records.
If feedback is sensitive, consider encryption (e.g., Shield Platform Encryption) for fields like feedback comments.

Reference:
Salesforce Help: Control Access to Records
Salesforce Help: Sharing Settings
Salesforce Documentation: Role Hierarchy Considerations

Explanation:

This request requires immediate action to block access while also handling a data integrity issue (the user being referenced in a lookup field).
Immediate Access Removal: The Freeze user option is the fastest and most appropriate way to immediately prevent a user from logging in. It is a single click (Setup -> Users -> Freeze) that takes effect instantly, fulfilling the "rush request" from HR.
Data Integrity: The user is referenced in a "Direct Manager" lookup field on other records. Simply deactivating or deleting the user would leave these references as "broken links" (showing the user's name but with a strikethrough). The correct administrative practice is to find all records where this user is the Direct Manager and update that field to a different, active user (or blank it). This cleans up the data and maintains the hierarchy's integrity.

Why the Other Options Are Incorrect:
B. Deactivate the user and delete any records where they are referenced... This is incorrect because deactivating the user already prevents login, making the "freeze" step redundant for access. More seriously, deleting the records that reference the user is a catastrophic action. The request is to remove a user's access, not to delete large amounts of company data (like employee records). This would cause massive data loss.
C. Change the user’s profile to read-only... This is incorrect and not immediate. A profile change does not necessarily prevent login; it just reduces permissions. This process is slower than using the Freeze function. Furthermore, it doesn't address the core issue of the user being referenced in the hierarchy field.
D. Delete the user and leave all records... This is incorrect for two major reasons. First, deleting a user is a complex process that is rarely recommended and often blocked by Salesforce to prevent data loss. Second, leaving "broken" lookup references is poor data hygiene. It would create confusion in reporting and hierarchy visibility, as the links to the deleted manager would be invalid.

Reference:
Salesforce Help: "Freeze and Unfreeze Users"
"Freezing a user logs the user out of Salesforce and prevents them from logging in again until an administrator unfreezes them. This is useful if you need to immediately disable a user’s access... A user license is still assigned to a frozen user."

Best Practice:
It is standard admin practice to use Freeze for immediate access revocation and then systematically update any lookup fields that reference the soon-to-be-deactivated user before finally deactivating them.

Explanation:

When users see different picklist options on the same object (like Opportunity) for different kinds of records, it's a direct result of Record Types.
Record Types allow an administrator to define different business processes, page layouts, and a subset of picklist values for different users based on their profiles.
In this scenario, Cloud Kicks likely has multiple Opportunity record types (e.g., "New Business," "Renewal," "Service").
Each of these record types can have its own specific set of available picklist values for fields, such as the "Shoe style" field. An administrator would go to each Record Type's settings to manage which picklist values are available for that specific type of opportunity.

Why the other options are incorrect:
A. Fields and relationships: This is where you would edit the field itself (like adding new values to the master picklist), but it doesn't control which values appear for specific record types.
B. Related lookup filters: Lookup filters restrict which records can be selected in a lookup field. They are not used to manage the values in a picklist.
D. Picklist value sets: Picklist value sets are used to create global picklists that can be shared across multiple objects, but the specific values available on a record are still controlled at the Record Type level.

Explanation:

The Highlights Panel in Lightning Experience displays fields from the Compact Layout, not from the standard page layout. Here's how it works:

🧩 B. In the Account object manager, create a custom compact layout ✅
To show a field in the Highlights Panel, you must:
Go to Object Manager → Account → Compact Layouts
Create or edit a compact layout
Add the custom text area field to the layout
Set it as the primary compact layout via the Compact Layout Assignment
This ensures the field appears in the Highlights Panel across Lightning pages.

❌ Why the Other Options Don’t Work:
A. Create a new page layout and a new section titled highlights panel
The Highlights Panel is not a section in page layout — it’s controlled by the Compact Layout, which is a separate configuration.
C. From the page layout editor, drag the field to the highlights panel
You cannot drag fields into the Highlights Panel from the page layout editor.
That panel is populated only via the Compact Layout.
D. Make the field required and move it to the top of the page
This affects the page layout, not the Highlights Panel.
Required fields are enforced during record creation/editing, but this doesn’t control visibility in the Highlights Panel.

🔗 Reference:
Salesforce Help: Compact Layouts
Trailhead: Customize a Salesforce Object

Explanation:

To address the issue of sales reps missing key fields on Opportunity records and ensure they cannot move to the next stage without completing required fields from previous stages, the administrator should implement solutions that enforce data entry, guide users, and prevent stage progression without compliance. The following three options are most effective:
B. Use Validation Rules:
Validation rules can enforce data quality by preventing users from saving an Opportunity record if key fields are missing or invalid for a specific stage. For example, a validation rule like AND(StageName = "Closed Won", ISBLANK(CloseDate)) would block saving the record if the Close Date is empty when moving to the "Closed Won" stage. This ensures reps complete required fields before advancing, addressing the requirement to prevent moving forward without prior stage data.
C. Configure Opportunity Path:
Opportunity Path is a visual tool in Salesforce that guides sales reps through the stages of the sales process. Administrators can configure it to highlight key fields for each Opportunity stage (e.g., Amount, Close Date, or Next Steps for the "Prospecting" stage). By marking fields as required in the Opportunity Path settings, reps are prompted to complete them before moving to the next stage. This provides a user-friendly way to ensure key fields are filled out and supports the requirement to guide reps through the process.
E. Mark fields required on the page layout:
Marking fields as required on the Opportunity page layout (via Object Manager > Opportunity > Page Layouts) ensures that reps must enter values for those fields before saving the record. This is a straightforward way to enforce data entry for key fields (e.g., Amount or Close Date) at any stage. However, this applies universally across all stages, so it should be used for fields that are always required, complementing stage-specific validation rules or Opportunity Path guidance.

Why not the other options?
A. Enable guided selling:
Guided selling typically refers to Salesforce features like Sales Path (part of Opportunity Path) or third-party CPQ (Configure, Price, Quote) solutions. While Opportunity Path is relevant (covered by option C), “guided selling” as a standalone term is vague and not a specific Salesforce feature for enforcing field requirements. It’s more about guiding the sales process broadly, not specifically addressing missing fields or stage progression rules.
D. Use Flow to mark fields required:
While Salesforce Flows can automate processes and include validation logic (e.g., a screen flow prompting users to fill in fields), they cannot directly “mark fields required” in the same way as page layouts or validation rules. Flows are better suited for complex, multi-step processes or dynamic interactions, not for enforcing field requirements across all Opportunity records. This makes it less practical for the stated need compared to validation rules or page layout settings.

Key Considerations for Northern Trail Outfitters:
Validation Rules: Create stage-specific validation rules to ensure key fields are populated before advancing. For example, AND(StageName = "Negotiation", ISBLANK(Amount)) could block progression if the Amount field is empty.
Opportunity Path: In Setup > Object Manager > Opportunity > Opportunity Path, configure key fields for each stage and enable prompts to guide reps. Ensure the path is visible on the Opportunity page layout.
Page Layout Requirements: Use sparingly for fields that are critical across all stages to avoid overly restrictive UX. Combine with validation rules for stage-specific enforcement.
Test the configuration in a sandbox to ensure it balances usability and enforcement without frustrating reps.

Reference:
Salesforce Help: Set Up Opportunity Path
Salesforce Help: Create Validation Rules
Salesforce Help: Make Fields Required

Explanation:

Global Picklist (B)
A Global Value Set allows you to define one central set of picklist values that can be reused across multiple objects (Accounts, Cases, etc.).
This ensures consistency—if you update the values in the global set, it’s reflected everywhere it’s used.
Perfect for DreamHouse Realty’s need to have the same Category values on both Accounts and Cases.

Custom Picklist (D)
You still need to create a custom picklist field on each object (Account and Case).
When creating the custom field, you can link it to the Global Value Set, so both objects share the same values.
With Record Types, you can show only the values relevant to that record type.

Why Not the Others?
A. Dependent Picklist
Dependent picklists control values based on another field’s value (e.g., Category → Subcategory).
The requirement here is consistent values across objects, not dependent values.
C. Multi-Select Picklist
Multi-select picklists allow users to select multiple values, but they are hard to report on and don’t ensure cross-object consistency.
Salesforce best practice is to avoid multi-select picklists unless absolutely necessary.

Reference:
Salesforce Help: Global Picklists (Global Value Sets)
Salesforce Help: Picklists for Record Types