At Universal Containers, there is a custom field on the Lead named Product Category. Management wants this information to be part of the Opportunity upon lead conversion. What action should the administrator take to satisfy the request?
A. Map the lead custom field to the product's product category field.
B. Create a workflow to update Opportunity fields based on the lead.
C. Create a custom field on the Opportunity and map the two fields.
D. Configure the product categories picklist field on the product.
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
The service manager at Ursa Major Solar wants to let customers know that they have received their cases via email and their websites. Medium-priority and high priority cases should receive different email notifications than low-priority cases. The administrator has created three email templates for this purpose. How should an administrator configure this requirement?
A. Include three assignment rules that fire when cases are created. Add a filter for case priority. Select the appropriate email template for each rule.
B. Add three auto-response rules. Configure one rule entry criteria for each rule and set a filter for case priority. Select the appropriate email template for each rule entry.
C. Configure one workflow rule that fires when cases are created. Add a filter for case priority. Select the appropriate email template for the rule.
D. Create one auto-response rule. Configure three rule entry criteria and set a filter for case priority. Select the appropriate email template for each rule entry.
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.
The Human resources department at Northern Trail outfitters wants employees to provide feedback about the manager using a custom object in Salesforce. It is important that managers are unable to see the feedback records from their staff. How should an administrator configure the custom object to meet this requirement?
A. Uncheck grant access using Hierarchies.
B. Define a criteria-based sharing rules.
C. Set the default external access to private.
D. Configure an owner-based sharing rules.
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
An administrator gets a rush request from Human Resources to remove a user’s access to Salesforce Immediately. The user is part of a hierarchy field called Direct Manager. What should the administrator do to fulfil the request?
A. Freeze the user to prevent them from logging in while removing them from being referenced in the Direct Manager field.
B. Deactivate the user and delete any records where they are referenced in the Direct Manager field.
C. Change the user’s profile to read-only while removing them from being referenced in the Direct Manager Field.
D. Delete the user and leave all records where they referenced in the Direct Manager Field without changes.
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.
Users at Cloud Kicks are reporting different options when uploading a custom picklist on the Opportunity object based on the kind of opportunity. Where Should an administrator update the option in the picklist?
A. Fields and relationships
B. Related lookup filters
C. Record Type
D. Picklist value sets
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.
An administrator Creates a custom text area field on the Account object and adds it to the service team's page layout. The services team manager loves the addition of this field and wants it to appear in the highlights panel so that the services reps can quickly find it when on the Account Page. How should the administrator accomplish this?
A. Create a new page layout and a new section titled highlights panel.
B. In the Account object manager, create a custom compact layout.
C. From the page layout editor, drag the field to the highlights panel.
D. Make the field required and move it to the top of the page.
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
Sales reps miss key fields when filling out on opportunity record through the process. Reps need to move forward Win unable to enter previous stage. Which three options should the administrator use to address this need?
(Choose Three answers)
A. Enable guided selling.
B. Use Validation Rules.
C. Configure Opportunity Path.
D. Use Flow to mark fields required.
E. Mark fields required on the page layout.
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
DreamHouse Reality needs to use consistent picklist value on a category filed on accounts and cases, with value respective to record types. Which two features should the administrator use to fulfill this requirement?
(Choose 2 Answers)
A. Dependent Picklist
B. Global Picklist
C. Multi-Select Picklist
D. Custom Picklist
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
Universal Containers (UC) would like to count the number of open cases associated with each account and update the account with this value everyFriday evening. UC has several hundred open cases at any given time. What should the administrator use to complete this request?
A. Use a record trigger flow.
B. Use a scheduled process builder.
C. Use a Roll-Up summary.
D. Use a scheduled flow
Explanation:
Because Cases are related to Accounts via a lookup relationship, you cannot use a roll-up summary field (which only works on master-detail relationships). A record-triggered flow or Process Builder cannot execute on a defined schedule; they run only when records are created or updated. Instead, a scheduled flow (also called a schedule-triggered flow) allows you to run automation at specified intervals—every Friday evening in this scenario—to query all open Cases, group them by Account, count them, and then update each Account record with the calculated count. Scheduled flows are more scalable and efficient than repeatedly triggering on each Case change, especially when dealing with several hundred open Cases. They also supersede the older “Scheduled Paths” in Process Builder, offering greater performance and flexibility.
Sales users at Universal Containers are reporting that it is taking a long time to edit opportunity records. Normally, the only field they are editing is the Stage field. Which two options should the administrator recommend to help simplify the process?
(Choose 2 answers)
A. Add a path for stage to the opportunity record page.
B. Use a Kanban list view for Opportunity.
C. Configure an auto launched flow for Opportunity editing
D. Create a simplified Opportunity page layout.
Explanation:
When users are only updating the Stage field, reducing page complexity speeds up their edits. Adding a Path component focuses attention on the Stage field by displaying it prominently at the top of the record page, guiding reps through key stages and required fields without navigating the full layout. Meanwhile, a simplified page layout that only includes essential fields and related lists minimizes load time and scrolling, so users can quickly save their changes. Although a Kanban view (option B) provides a board-style view of opportunities, it’s a list-view feature rather than editing the record page itself; an auto-launched flow (option C) would require users to trigger a separate flow, adding overhead rather than simplifying. Together, Path and a streamlined layout improve performance and user experience for routine Stage updates.
Sales raps at Ursa Solar are having difficulty managing deals. The leadership team has asked the administrator to help sales reps prioritize and close more deals. What should the administrator and close more deals.
A. Einstein Lead Scoring
B. Einstein Search Personalization
C. Einstein Activity Capture
D. Einstein Opportunity Scoring
Explanation:
Einstein Opportunity Scoring analyzes historical opportunity data and identifies key factors that indicate a deal’s likelihood to close, assigning each opportunity a score and recommending focus areas. By highlighting high-probability deals and indicating at-risk opportunities, Sales reps can prioritize their pipeline more effectively and close more deals. Einstein Lead Scoring (option A) scores leads rather than open opportunities. Einstein Activity Capture (option C) syncs emails and events but doesn’t provide predictive insights on deal health. Einstein Search Personalization (option B) optimizes search results for individual users. Thus, Einstein Opportunity Scoring is the right tool to help Ursa Solar’s leadership and sales reps focus efforts on the most promising deals.
Which tool should an administrator use to identify and fix potential session vulnerabilities?
A.
Field History Tracking
B.
Setup Audit Trail
C.
Security Health Check
D.
Organization-Wide Defaults
Security Health Check
Explanation:
Security Health Check analyzes your org’s security settings (including session settings, password policies, network access, and more) and compares them against the Salesforce Baseline Standard or a custom baseline. It highlights any settings that are less secure than recommended—such as session timeout, session fixation protection, or clickjack protection—and provides remediation steps. Field History Tracking (A) logs data changes, Setup Audit Trail (B) tracks metadata changes, and Organization-Wide Defaults (D) define record-level access; none evaluate session or security settings holistically. Therefore, the Security Health Check is the correct tool to identify and fix potential session vulnerabilities.
| Page 2 out of 21 Pages |
| Previous |