Explanation:

Parent-Child Relationship: In this scenario, Account is the parent (standard) object, and Box is the child (custom) object, since the lookup field was added from the Box object to the Account object.

Report Type Creation Logic: When you create a lookup relationship from a custom object to a standard object, Salesforce automatically creates a standard report type that starts with the standard object (the parent) and includes the related custom object (the child).

Report Scope: This Accounts with Boxes report type allows you to report on accounts and, in the same report, show the boxes that are related to them. This is a crucial distinction from a report that would start with the Box object.

"with or without" report types: To create a report that shows records from the parent object even if they don't have any related child records, you must manually create a custom report type.

Explanation:

The question asks for three common items that an app builder can move using change sets in Salesforce to support Universal Containers’ sandbox release schedule. Change sets are a deployment tool in Salesforce used to migrate metadata (configuration and code) between related orgs (e.g., from sandbox to production). Let’s analyze each option step-by-step to determine which items can be included in a change set:

A. Web-to-lead:
Web-to-lead is a Salesforce feature that generates HTML code for lead capture forms on external websites. While web-to-lead settings (e.g., default lead owner, form fields) are configurable, they are considered data or org-specific settings, not metadata. Change sets are used for metadata migration, and web-to-lead configurations cannot be included in a change set. This option is incorrect.
B. Standard fields:
Standard fields are predefined fields provided by Salesforce on standard objects (e.g., Name, CreatedDate on Account). These fields are part of Salesforce’s core platform and cannot be modified or migrated via change sets because they are not custom metadata. Only custom metadata or configurations (like custom fields or page layouts) can be included. This option is incorrect.
C. Custom object:
Custom objects are user-defined objects created to store specific data (e.g., a custom object for tracking projects). Custom objects, including their definitions, fields, relationships, and associated metadata (like page layouts or validation rules), are considered metadata and can be included in a change set. This is a common item moved by app builders during deployments, making this option correct.
D. Apex class:
Apex classes are custom code written in Salesforce’s Apex programming language to implement business logic. Apex classes are metadata and can be included in a change set for deployment between orgs. This is a common item for developers and app builders to migrate, especially when custom functionality is part of the release. This option is correct.
E. Custom field:
Custom fields are user-defined fields added to standard or custom objects to capture additional data (e.g., a custom “Project Deadline” field on a custom object). Custom fields, including their definitions and configurations, are metadata and can be included in a change set. This is a very common item for app builders to migrate, making this option correct.

Why These Three?
Custom object (C): Essential for deploying new data structures and associated configurations (e.g., fields, page layouts).
Apex class (D): Critical for deploying custom business logic, often part of complex release schedules.
Custom field (E): Commonly used to extend standard or custom objects, frequently included in change sets for schema updates.

These items are all metadata, align with the capabilities of change sets, and are commonly managed by app builders during deployments.

Additional Notes:
Change sets require a deployment connection between orgs (e.g., sandbox to production) and are limited to metadata components. Other tools, like Data Loader or third-party backup solutions, are needed for data migration (e.g., web-to-lead form data).
While standard field configurations (e.g., picklist values or field-level security) can sometimes be included in change sets, the fields themselves cannot, which rules out option B.

References:
Salesforce Help: Change Sets Overview – Describes change sets and the types of metadata components that can be included.
Salesforce Help: Components Available in Change Sets – Lists metadata types, including custom objects, Apex classes, and custom fields, that can be migrated.
Trailhead: Change Management – Covers deployment strategies, including using change sets for metadata migration.

Explanation:

This question tests knowledge of Salesforce mobile usability and record creation efficiency. Sales reps need to capture Feedback records related to Accounts with minimal clicks on mobile devices. Quick actions reduce navigation steps, and predefined field values eliminate manual data entry. The combination of an Account-specific quick action and default field values provides the fastest mobile experience.

✔️ Correct Option (A): Create a single-specific action in Account (object-specific quick action).
An object-specific quick action placed on the Account page layout allows sales reps to create a Feedback record directly from the Account detail page with one tap. This eliminates the need to navigate to the Feedback tab or search for the parent Account ID, significantly reducing clicks on mobile.

✔️ Correct Option (D): Create predefined values for most of the fields.
Predefining default values for Feedback fields (e.g., default Status, Type, or Rating) minimizes manual data entry. On mobile, typing is slow and error-prone. Default values allow reps to accept suggested values or change only a few fields, making record creation faster and more accurate.

❌ Incorrect Option (B): Create a feedback object as a parent of Account.
Making Feedback the parent of Account would create an incorrect data model. Feedback should be a child (detail) of Account (master) because one Account can have many Feedback records. A parent-child reversal would break standard reporting and make data entry illogical.

❌ Incorrect Option (C): Create a global action on Account.
This option is poorly phrased. A global action is not "on Account" – it appears globally in the Salesforce action bar. While a global action can create a Feedback record, it does not auto-populate the Account lookup field. Reps would manually search for the Account, adding extra clicks. An object-specific action on Account is superior for this requirement.

🔧 Reference:
→ Salesforce Help: Quick Actions for Mobile – Confirms object-specific quick actions reduce clicks on mobile by pre-populating parent record lookups.
→ Salesforce Trailhead: Minimize Data Entry with Default Values – Explains how predefined field values speed up record creation on mobile devices.

Explanation:

This question tests knowledge of dynamic UI behavior in Salesforce. The recruiting team wants the "Years of Previous Experience" number field to appear only when the "Previous Experience" checkbox is selected. This is a conditional field display requirement. Salesforce Dynamic Forms (available on Lightning Record Pages) allows hiding or showing fields based on component visibility rules without code or complex workarounds.

✔️ Correct Option (C): Use Dynamic Forms to display the Years of Previous Experience field if Previous Experience is checked.
Dynamic Forms enables conditional visibility on Lightning record pages. The app builder can add both fields to the page, then set a visibility rule on the "Years of Previous Experience" field so it displays only when the checkbox field "Previous Experience" equals true. This is declarative, real-time, and requires no code or multiple page layouts.

❌ Incorrect Option (A): Create two different page layouts and a process to change the layout if Previous Experience is checked.
Page layouts cannot be dynamically changed at runtime based on field values. A process or flow cannot switch a user's page layout after the page loads. This approach is technically impossible because layout assignment is based on profile, record type, or criteria at record creation—not on-the-fly checkbox changes.

❌ Incorrect Option (B): Create a dependency between the Previous Experience and Years of Previous Experience fields.
Field dependencies are available only between picklist fields (controlling field = picklist, dependent field = picklist). Field dependencies do NOT work with checkbox fields or number fields. This is a common misconception; checkboxes and number fields cannot be used in standard dependent field relationships.

❌ Incorrect Option (D): Use a Visualforce component on the candidate page layout to conditionally display the fields.
While a Visualforce page or component could achieve conditional display, it is overkill for such a simple requirement. Visualforce requires Apex knowledge, custom development, and ongoing maintenance. Dynamic Forms is the recommended declarative solution. Using Visualforce adds unnecessary complexity when a no-code solution exists.

🔧 Reference:
→ Salesforce Help: Dynamic Forms Conditional Visibility – Confirms that Dynamic Forms allows showing/hiding fields based on checkbox values without code.
→ Salesforce Trailhead: Dynamic Forms – Explains how to conditionally display fields on Lightning record pages using component visibility rules.

Explanation:

The user wants to allow an applicant to apply for multiple positions, and for a position to receive multiple applications. This is a classic many-to-many relationship scenario, which cannot be modeled with a single master-detail or lookup relationship in Salesforce.

Junction Object:
A third, intermediary custom object must be created to link the two primary objects (Applicant__c and Open_Position__c). In this case, the Application__c object serves as the junction object.
Master-Detail Relationships:
The junction object (Application__c) needs to have two master-detail relationships—one to Applicant__c and one to Open_Position__c. This allows a single Applicant__c record to be linked to multiple Application__c records, and a single Open_Position__c record to be linked to multiple Application__c records, effectively creating the many-to-many relationship.

Breakdown of the options:
A. Create a master-detail relationship on Open_Position__c to Application__c:
This is one part of the solution, but it's not the complete picture. This alone would imply a one-to-many relationship from the application to the position.
B. Create a master-detail relationship held on Applicant__c to Application__c:
This is also only one part of the solution. The master-detail fields should be on the junction object (Application__c), not the master objects.
C. Create a master-detail relationship field on Application__c to Open_Position__c:
This is one of the two relationships needed on the junction object.
D. Create a master-detail relationship field on Applicant__c to Apphcabon_c:
This option contains a typo (Apphcabon_c) and describes only one side of the relationship. It is also incomplete.

The most accurate and complete recommendation would involve creating the junction object Application__c and then creating the two master-detail relationship fields on it. Given the choices, none are complete, but C is one of the two relationships required.