Explanation:

This question tests knowledge of Salesforce automation, approval workflows, and record-tracking capabilities. The marketing director has two distinct needs: (1) tracking discounts, samples, and giveaways by Sales Rep for reporting purposes, and (2) enforcing a mandatory manager sign-off before free parts can be given away. The first requirement can be met with custom fields and reports, but the second—automated, auditable manager authorization—requires an Approval Process.

✔️ Correct Option (C): Approval process
An Approval Process is the correct tool because it automates multi-step review and sign-off on records (e.g., Opportunity, Order, or custom object). It can route free-part requests to the appropriate manager, require comments, capture approval/rejection decisions, and maintain a full audit trail. This ensures compliance: no free parts are given without documented manager authorization. Additionally, approval history fields can be used in reports to track which Sales Rep requested free parts and whether they were approved or denied.

❌ Incorrect Option (A): High Velocity Sales
High Velocity Sales is a Lightning-specific sales engagement solution designed for outbound calling, lead prioritization, email cadences, and coaching. It does not include any native manager approval workflow capabilities, nor does it track discounts or giveaways in a structured, record-based manner. It is a productivity tool, not an approval or compliance tool.

❌ Incorrect Option (B): Quotes
Quotes allow sales teams to generate price documents with product line items, discounts, and totals. While a Quote could technically show free parts, it does not provide an automated, rules-based manager sign-off process with routing, notifications, or approval history. Quotes are for customer-facing pricing, not internal authorization workflows. Using Quotes would require manual manager review outside of Salesforce.

❌ Incorrect Option (D): Check box
A checkbox field (e.g., "Manager Approved") can store a binary yes/no value, but it cannot enforce a process. It does not route requests to the right manager, prevent free parts from being given without approval, capture rejection reasons, or track approval history. A checkbox alone provides no automation, no notifications, and no audit trail—making it insufficient for compliance requirements.

🔧 Reference:
→ Salesforce Help: Approval Process Overview – Confirms approval processes automate record-based sign-offs, routing, and approval history tracking.
→ Salesforce Trailhead: Manage Approvals – Explains how to set up multi-step approval workflows for manager sign-off on records like discounts or free items.

Explanation:

This question tests the best practice for decoupling a formula field on Opportunity from its parent Account while allowing future manual edits and preserving historical data.

✅ Correct Option:

D. Create a new text field and import the formula field values in it.
This is the recommended solution. Create a new Text field on the Opportunity object. Then use Data Loader or Import Wizard to copy the current calculated values from the existing formula field into the new field. Once migrated, make the new field visible for editing and optionally hide the old formula field. This ensures existing records retain their values while allowing sales reps to enter different Specialty values going forward.

❌ Incorrect options:

A. Extend the data, convert the field to GETTING and mount the data.
This option is technically invalid. Formula fields cannot be converted this way, and the terms used do not correspond to any Salesforce functionality. It risks data integrity issues.

B. Convert the field to a text field and the values in the left.
Directly converting a formula field to Text is not safe and can result in loss of the formula or calculated values. Salesforce does not support straightforward conversion while preserving data reliably.

C. Create a new text field and keep using the existing formula field.
This does not meet the requirement. The formula field remains read-only and will continue pulling values from the Account, preventing sales reps from entering independent values on Opportunities.

🔧 Reference:
→ Create Custom Fields - Salesforce Help
Confirms how to add new editable custom fields on objects.

→ Data Loader Overview
Explains exporting from formula fields and importing values into new fields.

Explanation:
Ursa Major Solar needs to auto-populate a field on the Asset record with the last maintenance date whenever a maintenance work order is closed. This requirement involves updating a parent record (Asset) based on changes in a related child record (Work Order).

The best declarative tool for this is Flow, specifically a Record-Triggered Flow:
It can be triggered when a Work Order record is updated (e.g., status changes to “Closed”).
It can check if the Work Order type is “Maintenance.”
It can then update the related Asset record with the Work Order’s closed date.
This ensures automation without custom code, aligning with Salesforce’s declarative-first approach emphasized in the exam.

Why Other Options Are Incorrect

A. Einstein Next Best Action
Provides recommendations to users based on business rules or predictive models.
It does not update fields or enforce automation when records change.

B. Roll-up Summary
Roll-up summary fields aggregate values (COUNT, SUM, MIN, MAX) from child records into a parent record.
They cannot selectively update a field with the “last maintenance date” because that requires conditional logic (only maintenance work orders, only when closed).

C. Apex Trigger
Apex could achieve this, but it requires custom code.
Since this requirement can be met declaratively with Flow, Apex is not the recommended solution. Salesforce exams emphasize using declarative tools first unless code is unavoidable.

Exam-Oriented Reasoning
The key phrase is “auto-populated on the Asset record when a maintenance work order gets closed.”
Roll-up summaries cannot handle conditional logic like “only maintenance work orders.”
Einstein Next Best Action is about recommendations, not automation.
Apex is powerful but not exam-best practice unless declarative tools fail.
Flow is the correct declarative automation tool for updating parent records based on child record changes with conditional logic.

References
Salesforce Help: Record-Triggered Flows
Salesforce Help: Roll-Up Summary Fields

Explanation:
Universal Containers needs a picklist field called Status on three separate custom objects, and the values must be shared across all three objects. The only Salesforce feature that supports this requirement is a Global Picklist Value Set.

A Global Picklist Value Set allows administrators to define a single set of picklist values that can be reused across multiple objects and fields.
This ensures consistency of values (e.g., “New,” “In Progress,” “Closed”) across all objects.
It also simplifies maintenance: if UC wants to add or remove a value, they only update the global value set once, and all fields using it are updated automatically.
This is the declarative, best-practice solution for sharing picklist values across multiple objects.

Why Other Options Are Incorrect

A. Related Picklist
Salesforce does not have a feature called “Related Picklist.” This is a distractor option.

B. Shared Custom Field
Fields cannot be “shared” across objects. Each object has its own fields. You can replicate fields, but values cannot be centrally managed unless you use a global picklist value set.

D. Dependent Picklist
Dependent picklists are used when one picklist’s values depend on another field’s value (e.g., Country → State).
They do not allow sharing values across multiple objects.

Exam-Oriented Reasoning
The keyword in the scenario is “share the list of values across each object.”
Distractors like “Shared Custom Field” or “Related Picklist” test whether you know Salesforce’s actual features.
“Dependent Picklist” is a common misdirection, but it applies only to conditional logic, not shared values.
The only valid Salesforce feature for this requirement is Global Picklist Value Set.
Thus, the correct answer is C.


References
Salesforce Help: Global Picklist Value Sets

Explanation:

Ursa Major Solar wants to model a scenario where:
A Job Candidate can apply for multiple Open Positions.
Each Open Position can have multiple Applications. Both the Job Candidate record and the Open Position record should display the related Applications.
This is a classic junction object use case in Salesforce. The Application__c object acts as the junction object between Job_Candidate__c and Open_Position__c.

To achieve this:

Application__c → Job_Candidate__c (Master-Detail): This relationship ensures that each application is tied to a specific candidate. On the Job Candidate record, you can see all related Applications.

Application__c → Open_Position__c (Master-Detail): This relationship ensures that each application is tied to a specific open position. On the Open Position record, you can see all related Applications.

By creating two master-detail relationships on Application__c, Salesforce automatically provides related lists on both parent objects (Job Candidate and Open Position). This satisfies the requirement to view applications from both perspectives.

Why Other Options Are Incorrect

A. Create a master-detail relationship on Open_Position__c to Application__c
Incorrect because the master-detail must be defined on the child (Application__c), not on the parent (Open_Position__c). Parent objects cannot directly hold master-detail fields pointing to children.

B. Create a master-detail relationship field on Job_Candidate__c to Application__c
Incorrect for the same reason. The child (Application__c) must hold the master-detail field pointing to the parent (Job Candidate). You cannot define a master-detail on the parent object to the child.

Exam-Oriented Reasoning
This question tests your ability to recognize junction object design. When two objects need to have a many-to-many relationship (Job Candidates ↔ Open Positions), you create a third object (Applications) with two master-detail relationships pointing to each parent.

References
Salesforce Help: Understanding Master-Detail Relationships
Trailhead: Data Modeling – Many-to-Many Relationships