Explanation:

In Salesforce Field Service, Relevance Groups allow you to apply specific Work Rules or Service Objectives to a subset of your Service Resources rather than the entire team.

Why this is the correct configuration:

Selective Enforcement: By default, a "Maximum Travel from Home" rule applies to everyone in a territory. However, if your internal employees are allowed to travel 2 hours but this specific contractor is limited to 50 minutes, you need a way to distinguish them.

Criteria-Based Filtering: You can create a Relevance Group based on a field (e.g., Resource Type = Contractor or a custom checkbox like Limited Travel).

The "Maximum Travel from Home" Rule: You then create a Maximum Travel from Home work rule, set it to 50 minutes, and link it to that specific Relevance Group.

Result: When the scheduling engine runs, it will only enforce the 50-minute limit for the contractor, while internal technicians continue to follow the standard company rules.

🔴 Incorrect Answers

B. Assign a high efficiency score.
The Efficiency field on the Service Resource record is used to estimate how long a job will take (e.g., an efficiency of 2.0 means a technician finishes in half the standard time). It does not control travel distance or geographic boundaries.

C. Check 'Keep These Appointments Scheduled'.
This checkbox (usually found on the Service Appointment record) is used to prevent the Optimization engine from moving an appointment that has already been scheduled. It is a "pinning" mechanism and has no impact on the initial rules governing how far a resource can travel.

D. Include a Match Fields work rule.
The Match Fields work rule is used to ensure a field on the Service Appointment (like "Language") matches a field on the Service Resource. It is a binary match-making tool and cannot calculate or limit geographical travel time or distance.

📖 References
Salesforce Help: Work Rule Relevance Groups
Salesforce Help: Work Rule Type: Maximum Travel from Home
Trailhead: Create and Manage Work Rules

Explanation:

Technicians using the Field Service Lightning mobile app need to view and track progress directly from the Work Order Line Item card. Salesforce provides this functionality natively through page layouts and related lists, without requiring custom development.

Work Order Line Items Related List (A):
Work Order Line Items represent the individual tasks or components of a job.
By adding the Work Order Line Items related list to the Work Order page layout, technicians can see all tasks associated with the job in the mobile app.
Assigning this layout to the technician’s profile ensures that when they open a Work Order in the mobile app, they see the line-item card with progress details.
This is the standard, recommended configuration approach — simple, declarative, and mobile-ready.

Why not the other options?
B. Create a custom Visualforce page: Visualforce is not mobile-optimized for Field Service Lightning. It requires external links and browser access, which is not a seamless mobile app experience.

C. Create a custom Lightning component: While possible, this is unnecessary. Salesforce already provides Work Order Line Item visibility through page layouts. Custom components add complexity and maintenance overhead.

D. Create a report chart and link it to Service Appointment layout: Reports and charts are useful for managers, not technicians in the field. Linking a chart does not provide interactive progress tracking at the line-item level.

Best Practice:
Always leverage standard related lists and page layouts in the FSL mobile app before considering custom development.
This ensures consistency, reduces maintenance, and aligns with Salesforce’s mobile-first design.

Reference:
Salesforce Help: Work Orders and Work Order Line Items
Trailhead: Field Service Work Orders

Explanation:

Why this is correct:
In the call-center flow, the Case is the customer-reported issue. If it requires on-site work, you convert that into field work by creating a Work Order (the work to be performed). To actually schedule and send a technician, you then create a Service Appointment (the schedulable/dispatchable visit on the Gantt). Finally, you dispatch the Service Appointment to the technician.

Correct object roles:
Case = customer issue intake / support tracking
Work Order = field work record (what needs doing)
Service Appointment = scheduled visit (what gets dispatched)

Why the other options aren’t correct:

A puts Service Appointment before Work Order (normally the appointment is tied to the WO and represents the visit for that work).
B attempts to “dispatch work order” (dispatching is done on Service Appointments, not Work Orders).
D starts with a Service Appointment before the Case/Work Order context exists, which is backwards for a call-center intake process.

Explanation:

Why These Are Correct

A. Use all-or-none scheduling
Ensures related appointments are scheduled together. If one cannot be scheduled, neither is scheduled, maintaining consistency.

B. Dependency Type set to Start After Finish and Same Day
This enforces sequencing, ensuring the sales appointment is completed before the service appointment begins, and both occur on the same day.

D. Same Resource and Same Day fields on the page layout
These fields allow dispatchers to enforce that both appointments are assigned to the same technician and scheduled on the same day.

Why the Other Options Are Incorrect

C. Same start times
This contradicts the requirement that one appointment must finish before the next begins.

E. Complex Work Visualforce page
This is legacy functionality and not required for sequencing or simultaneous scheduling.

References
Salesforce Help: Service Appointment Dependencies
Trailhead: Field Service Scheduling

Explanation:

This question tests how to enforce a business process rule (Work Order cannot close without a signed Service Report) using a combination of status management and data validation.

Analysis of Correct Answers:

C. Custom Work Order Status: Create a new status, e.g., "Awaiting Customer Sign-off" or "Service Report Pending." This status would be a non-closed status in the picklist. The business process would require the Work Order to be in this state after work is completed but before the final closed status (like "Closed") is selected. This provides clear visibility into which jobs are pending sign-off.

D. Custom Validation Rule on Work Orders: This is the enforcement mechanism. The validation rule would prevent the status from being updated to a closed status value (e.g., "Completed," "Closed") unless a condition is met. That condition would check for the existence of a related, signed Service Report. For example, the rule could fire when ISPICKVAL(Status, "Closed") is true and Service_Report_Signed__c is false (or a related Service Report record with a signature does not exist). This rule technically prevents closure without the sign-off.

Together, these configurations create a controlled workflow: The custom status tracks the stage, and the validation rule blocks the final step unless the sign-off exists.

Why the other options are incorrect:

A. Custom Work Order Escalation Rules:
Escalation Rules are for automatically reassigning records or sending alerts when they sit in a queue too long. They do not prevent a record from being closed; they react to records that are already in an open state for too long.

B. Custom Approval Process on Work Orders:
An Approval Process is for routing records for managerial approval based on criteria. While you could design an approval to be required before closing, it is a heavier, multi-step process involving user approvals. The requirement is a direct data dependency (no sign-off, no close), which is more simply and directly enforced by a Validation Rule. An approval process would be over-engineered for this direct check.

Reference:
Validation Rules: A standard Salesforce feature to enforce data integrity by preventing saves unless criteria are met.
Status Picklists: Customizing the status picklist to reflect business stages is a common practice.

The combination of a custom status (for process clarity) and a validation rule (for enforcement) is a classic declarative pattern for gating record stage transitions based on related record criteria.