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:

This question evaluates your knowledge of data modeling in Salesforce, specifically choosing between Lookup and Master-Detail relationships. It tests your ability to model a one-to-many relationship where child records roll up summary information to a parent record.

✅ Correct Option:

✅ C. Custom object with Master-detail field to Opportunity
Creating a custom Help Request object with a Master-Detail relationship pointing to the Opportunity satisfies all requirements. Since an Opportunity can have multiple requests, the Opportunity acts as the master (parent) and the custom object acts as the detail (child). This configuration allows the app builder to create a Roll-Up Summary field on the Opportunity to automatically calculate and display the date of the most recent request using the MAX function.

❌ Incorrect options:

❌ A. Opportunity with Master-detail field to custom object
Placing the Master-Detail field on the Opportunity would make the custom Help Request object the parent. This configuration implies that one Help Request could have multiple Opportunities, which contradicts the business requirement where a single complex Opportunity needs multiple help requests.

❌ B. Custom object with Lookup field to Opportunity
While a Lookup field creates a one-to-many relationship allowing multiple help requests to link to one Opportunity, it does not support Roll-Up Summary fields. Without a Master-Detail relationship, you cannot automatically bubble up and display the most recent request date on the Opportunity page using standard declarative tools.

❌ D. Opportunity with Lookup field to custom object
Placing a Lookup field on the Opportunity means each Opportunity record could only link to a single Help Request record at a time. This structural design completely fails to support the requirement where complex opportunities need to track many different requests for help.

🔧 Reference:
→ Salesforce Help: Object Relationships Overview confirms that Master-Detail relationships are required to create Roll-Up Summary fields to display aggregate child data on parent records.

Explanation:

This question tests understanding of Salesforce security model combining record-level and field-level security. The requirements involve two distinct needs: (1) controlling who can access scorecard records (sales reps, managers, executives) and (2) preventing reps from viewing specific fields (executive comments).

✔️ Option B (Correct):
A Private sharing model with hierarchy-based access allows the record owner (sales rep) and users above them in the role hierarchy (managers and executives) to view the scorecard records automatically. This matches the requirement perfectly. Field-Level Security (FLS) on the executive comment field prevents sales reps from viewing that specific field while still allowing managers and executives to see it. FLS is the only way to restrict field access for specific profiles, making this the correct two-part solution.

❌ Option A (Incorrect):
Using custom settings for record access is unnecessary and overly complex when the role hierarchy naturally provides the required access pattern (rep → manager → executive). More critically, record types and page layouts cannot prevent field access—page layouts only control field visibility, and FLS overrides them. Record types control picklist values and page layout assignments, not field-level access restriction.

❌ Option C (Incorrect):
Custom settings are not needed since the role hierarchy automatically grants access to managers and executives above the sales rep. While page layouts and field-level security is closer to correct, page layouts alone don't enforce field security—FLS does. The hierarchy approach is the proper, native way to grant record access to managers and executives in the reporting chain.

❌ Option D (Incorrect):
While hierarchy-based sharing and field-level security are both correct, record types are unnecessary for this requirement. Record types control different picklist values and page layout assignments for different business processes, not field visibility. Field-level security alone is sufficient to hide the executive comment field from sales reps without needing record types.

🔧 Reference:
→ Salesforce Hierarchical Sharing Structure and Record Visibility – Salesforce Help
Confirms that Private sharing model with hierarchy allows record owner and users above in hierarchy to access records, and Field-Level Security restricts field access.

Explanation:

This question evaluates your understanding of manual sharing in Salesforce. When an object's Organization-Wide Default (OWD) is set to Private, a record owner or administrator can share specific individual records with other entities to extend access on an ad-hoc basis.

✅ Correct Options:

✅ C. Users
Manual sharing allows the record owner to grant access directly to an individual user. This is ideal for case-by-case scenarios where a single colleague who falls outside standard sharing rules needs visibility into a specific transaction or record.

✅ D. Public Groups
Public Groups are collections of individual users, roles, or other groups created by an administrator. Granting manual access to a Public Group gives everyone within that group immediate visibility into the specific record, simplifying administration when sharing with multi-disciplinary departments.

✅ E. Roles and Subordinates
Selecting this option allows a record owner to share an item with a manager and everyone who sits below that manager in the role hierarchy. This handles situational department-wide sharing requirements quickly without needing to select users individually.

❌ Incorrect options:

❌ A. Permission Set Groups
Permission Set Groups are used to bundle multiple permission sets together to assign functional system or object-level permissions (like Read, Create, Edit) to users. They control profile-like capabilities across the org, but they cannot be targeted as recipients for manual record sharing.

❌ B. Private Groups
Private Groups are user-generated spaces within Salesforce Chatter used for private team collaboration and discussions. While they control access to Chatter feeds and files posted within that group, they are not structural sharing entities used to grant record-level row access.

🔧 Reference:
→ Salesforce Help: Share Records Manually confirms that manual sharing allows record access to be granted to Users, Public Groups, Roles, and Roles and Subordinates.

Explanation:

This question tests knowledge of Salesforce sandbox types and their specific capabilities. The requirements are: (1) user acceptance testing (UAT), (2) approximately 500MB of data using a template, and (3) weekly refresh. Among all sandbox types, only Partial Copy sandbox supports data templates for selective data copying and allows refresh every 5 days (suitable for weekly), while fitting the 500MB data size requirement.

✔️ Correct Option (D): Partial Copy sandbox
A Partial Copy sandbox supports up to 5GB of data (500MB fits easily), allows data seeding using a sandbox template to select specific records and objects, and can be refreshed every 5 days (weekly is acceptable). It is specifically designed for UAT, integration testing, and training, providing a realistic data set without copying the entire production database.

❌ Incorrect Option (A): Full sandbox
A Full sandbox copies all production data and metadata. While it can handle 500MB easily, it can only be refreshed every 29 days (not weekly). It is intended for performance testing, load testing, and final pre-production validation, not for rapid weekly UAT cycles. It also consumes significant storage and time to refresh.

❌ Incorrect Option (B): Developer File sandbox
"Developer File sandbox" is not a valid Salesforce sandbox type. The correct names are: Developer, Developer Pro, Partial Copy, and Full Sandbox. This option is a distractor with no official existence in Salesforce documentation.

❌ Incorrect Option (C): Developer sandbox
A Developer sandbox copies only metadata (custom objects, fields, code) but no actual record data. It cannot meet the 500MB data requirement because it contains zero data rows. It is intended for coding and unit testing, not for UAT with realistic data volumes.

🔧 Reference:
→ Salesforce Help: Sandbox Licenses and Storage Limits by Type – Confirms Partial Copy sandbox supports sandbox templates, up to 5GB data, and 5-day refresh interval.
→ Salesforce Trailhead: Sandbox Configuration – Explains each sandbox type's use case, including Partial Copy for UAT with selective data.