Explanation:

To configure a Scheduled Optimization Job in Salesforce Field Service, you must define the scope of the work to be optimized and the rules by which that work should be scheduled.
The two required objects for this configuration are:

A. Service Territory
An optimization job needs to know where the work is located. In the Field Service Admin settings, when you create a new scheduled job, you must select one or more Service Territories. The optimization engine uses this to group Service Appointments and Service Resources that belong to those specific territories to run the calculations.

Option B: Scheduling Policy
A Scheduling Policy is a bundle of Rules (hard constraints, like "Match Skills") and Objectives (goals, like "Minimize Travel"). The optimization job requires a policy to understand the criteria it must follow to produce the "best" schedule. Without a policy, the engine wouldn't know whether to prioritize speed, cost, or technician preference.

Incorrect Answers

Option C: Work Type
While Work Types are essential for creating Work Orders and Service Appointments with consistent durations and required skills, they are not a direct configuration requirement for the Optimization Job itself. Optimization acts upon the Service Appointments already created from those Work Types.

Option D: Polygons
Polygons are used for map-based territory management (visualizing boundaries on the Dispatcher Console) and can be used to assign appointments to territories. However, they are an optional feature for territory management and are not a required field when setting up a scheduled optimization job.

References
Salesforce Help: Create and Manage Scheduling Policies
Salesforce Help: Set Up Scheduled Optimization Jobs

Explanation:

In Salesforce Field Service Lightning, the Extended Match work rule assigns Service Resources based on related object records (via a junction or linking object).

This rule matches a field on the Service Appointment (or related object like Work Order) to a field on the Service Resource through an intermediate custom junction object.

Common scenarios include matching on complex criteria like postal code coverage areas, product expertise, or customer preferences stored on related records (e.g., a "Coverage" object linking ZIP codes to resources).

It extends beyond direct field matching, enabling indirect relationships for advanced assignment logic.

The other options do not support related object-based matching:

A. Resource Availability — Checks shift hours, absences, and capacity but not related records.

C. Required Resource — Enforces assignment to a specific named/preferred resource on the appointment (direct lookup, not via related objects).

D. Match Field — Matches direct fields on Service Appointment to fields on Service Resource (e.g., a custom Language field on both)—no junction/related object involved.

Reference:
Salesforce Help: Work Rule Type - Extended Match – "Use the Extended Match work rule type to schedule service appointments using custom criteria. It uses a junction, or linking, object to match a field on the Service Appointment object to a related field on the Service Resource object."

Common in Field Service Consultant exam questions testing advanced work rules for indirect/related record matching.

Explanation:

Why This Is Correct
The Case object is the central record for customer support interactions in Service Cloud. When a customer calls in, the support agent typically works within a Case to track the issue. Once eligibility is confirmed through entitlements, the next step is to create a Work Order for on-site service.

By placing a Quick Action on the Case object, agents can seamlessly generate Work Orders directly from the Case record. This ensures that the Work Order is linked to the Case, maintaining a clear relationship between the customer’s reported issue and the field service work performed. It also streamlines the workflow for agents, reducing clicks and ensuring consistency.

Why the Other Options Are Incorrect
A. Entitlement: Entitlements define service eligibility but are not the operational record where agents work.
B. Opportunity: Opportunities track sales, not service issues.
D. Contact: Contacts represent people, but service workflows are managed through Cases.

References
Salesforce Help: Work Orders and Cases

Explanation:

Universal Containers is implementing Crew Management in Salesforce Field Service Lightning to handle group-based dispatching (e.g., teams of technicians for complex jobs). Crews are Service Crew records that aggregate individual Service Resources (crew members), allowing scheduling of the entire crew as a single bookable unit on the Gantt with combined capacity, skills, and availability.

A key consideration for consultants is:

B. Capacity-based scheduling is supported for Service Crews.
This is a critical capability and limitation nuance. Field Service supports capacity-based scheduling for Crews via Scheduling Policies (using the Utilization Threshold service objective, which considers total crew capacity against appointment duration). However, it uses the sum of crew members' capacities (not true aggregate planning like individual overtime). Crews appear as single resources on the Gantt with combined travel times (from the Crew Member who is also a Service Resource with a vehicle). This must be considered for accurate multi-technician job planning, especially for varying crew sizes. Capacity rules ensure overload prevention, but planners should validate totals manually for large crews.

Why the other options are incorrect (common pitfalls/misconceptions):
A. A service resource can only be a member of a single Crew.
False. Service Resources can be members of multiple Crews (via the Service Crew Member junction object). This flexibility supports scenarios like shared specialists across teams, but requires careful capacity management to avoid double-booking.

C. The Preferred Resource service objective is ignored for active Crew Members.
False. The Preferred Resource objective (in Scheduling Policies) prioritizes named preferred technicians on Work Orders and applies to Crew Members. It influences crew assignment/optimization if the preferred resource is an eligible crew member.

D. Salesforce Field Service considers the Recommended Crew Size when assigning appointments.
False. The Recommended Crew Size field on Work Types (e.g., "3 technicians needed") is informational/metadata only—it standardizes planning but is not used by the Scheduler, Optimizer, or Gantt for automatic assignment/resizing. Dispatchers must manually form/select appropriately sized crews.

Key Recommendation Considerations for Crews (beyond the answer):
- Enable Field Service Crew permissions and create Service Crew records with a designated Related Service Resource (for travel/home base).
- Use Crew Goals on Work Types for size guidance (not enforced).
- Test Scheduling Policies with Match Skills (crew aggregate skills) and Utilization for capacity.
- Mobile app supports crew check-in/out, but inventory/Products Consumed are individual.

Reference:
Salesforce Help: Schedule Service Crews – "Capacity-based scheduling... considers the combined capacity of crew members." Confirms support with caveats on aggregation.
Crew Limitations & Considerations: No single-crew restriction; Preferred Resource applies; Recommended Size is "planning guidance only."
Field Service Scheduling Policies – Utilization for crews.
Exam prep sites (Pass4Future, CourseHero) list B as correct for this exact/variant question, aligning with docs.
This question tests Crew Management implementation nuances, emphasizing capacity handling as a core consultant consideration for client scalability.

Explanation:

A: Select Working Location Enable Primary on the Working Territories Work Rule.
The Working Territories work rule enforces primary + secondary territory memberships. By default, it considers only secondary territories; selecting Working Location Enable Primary tells the optimizer to also consider the primary territory.

B: Remove the Match Territory Work Rule.
A scheduling policy can’t include both a Working Territories work rule and a Match Territory work rule for the same dataset—so to use Working Territories (to consider secondary territories), you must remove Match Territory.

Why not C or D?

C: Include the Match Territory Work Rule — Match Territory is the “hard boundary” rule and doesn’t meet the need to consider secondary territories; plus it conflicts with Working Territories in the same policy.

D: Deselect Working Location Enable Primary — That would make Working Territories consider only secondary territories (excluding primary), which contradicts UC’s requirement to still use the primary territory too.