Explanation

In Salesforce Field Service, Service Territories and Locations have a many-to-many relationship. Salesforce models this relationship using the standard junction object called Service Territory Location (ServiceTerritoryLocation).

Because this relationship is handled by a junction object:
You do not create custom lookup fields.
You expose the relationship using related lists on both parent objects.

Why A is correct
Adding the Service Territory Location related list to the Service Territory page layout allows users to see all Locations assigned to that Territory.

Why B is correct
Adding the Service Territory Location related list to the Location page layout allows users to see all Territories that the Location belongs to.

This is the standard and recommended configuration during Field Service setup.

❌ Why the other options are incorrect
C. Create the Service Territory Location as a Service Territory lookup field
❌ Incorrect — Salesforce already provides a standard association object. Creating a lookup would break the standard data model.

D. Create the Service Territory Location as a Location lookup field
❌ Incorrect — same reason. The relationship is not modeled via direct lookups, but via the ServiceTerritoryLocation object.

🔗 Salesforce References
Salesforce Help – Service Territory Location Object
Explains the standard junction object used to associate Locations and Service Territories

Salesforce Help – Set Up Service Territories
Describes how territories and locations are related during Field Service configuration

Trailhead – Configure Service Territories
Hands-on module covering territories, locations, and their associations

Explanation:

This question tests your understanding of where to define planned inventory requirements (the bill of materials) for jobs in Field Service Lightning. The goal is to track and manage what parts are needed so they can be provided to technicians.

Analysis of Correct Answers:
A. Products Required for Work Orders: The "Products Required" related list on the Work Order object is the primary, high-level place to define the parts needed for the entire job. This list aggregates all parts required across the various tasks. It is used for inventory planning, creating Product Requests to move parts to the technician's van, and generating picklists. This ensures the overall job's material needs are tracked.

C. Products Required for Work Order Line Items: For more granular tracking, especially when a Work Order has multiple line items representing different tasks or assets, you can define "Products Required" on individual Work Order Line Items. This allows you to specify which specific parts are needed for each discrete task or for each specific asset being serviced. This provides precise tracking and is essential if different line items have different part requirements.
Both methods are valid and often used together for comprehensive inventory management. The Work Order-level list gives a summary, while the Work Order Line Item list provides detailed attribution.

Why the other options are incorrect:
B. Products Required for Service Appointments: There is no standard "Products Required" related list on the Service Appointment object. Service Appointments are for scheduling time slots, not for defining the scope of work or material requirements. Inventory planning is tied to the work definition (Work Order/WOLI), not the schedule slot.

D. Products Required for Service Resources: This is not a standard feature. Service Resources represent technicians, not inventory stock. While you can track what inventory is physically located with a resource (via Product Items at a mobile Location), you do not define what parts a job requires on the Resource record itself. Requirements are defined on the work to be performed, not on the technician.

Reference:
Salesforce Help: "Add Products to Work Orders and Work Order Line Items" – This article explains both methods: "You can add products to work orders or work order line items to indicate which products are needed to complete the work... Adding products to work order line items is useful if different line items require different products."
The core principle is that inventory requirements are defined as part of the work definition (Work Order and its child Work Order Line Items), enabling the system to generate Product Requests and manage Product Transfers to get the right parts to the right place.

Explanation:

Universal Containers has 100 external contractors:
75 contractors need access to Work Orders, Assets, the Field Service mobile app, and Chatter.
These are field technicians performing work. For external users, they require the Field Service Contractor license (often a login-based or community-based license, such as Partner Community or Customer Community Plus with Field Service permissions). This provides access to the mobile app for viewing/updating work orders and service appointments, assets, and Chatter collaboration via communities.
The remaining 25 contractors are paid commissions on sales and need to schedule resources.
These act as dispatchers or managers who schedule field resources (assigning service appointments, managing crews, etc.). For external users needing scheduling capabilities (e.g., access to the Dispatcher Console or scheduling tools), they require the Field Service Contractor Plus license. This extends the standard Contractor license to include dispatcher-like functionality for external partners.

Option B recommends:
25 Contractor Plus licenses (for the scheduling group).
75 Contractor licenses (for the mobile/field access group).
This matches the differentiated needs while optimizing costs for external users (Contractor licenses are typically cheaper and login-based).

The other options do not align:
A suggests all 100 get the higher-tier Contractor Plus, which is overkill for the 75 who don't need scheduling.
C reverses the quantities, giving scheduling access to too many and insufficient mobile/dispatcher split.

Reference:
Salesforce official pricing and licensing for Field Service includes distinct Contractor (for technicians/mobile access) and Contractor Plus (for extended dispatcher/scheduling access for external users):
Help documentation on setting up contractors emphasizes community licenses with Field Service permissions, and Contractor Plus for advanced needs.

Explanation:

In a Private sharing model, the User Territory feature automatically shares the following objects with users assigned to that territory:

B. Service Resources
To manage a territory, dispatchers and managers must be able to see the individuals available to do the work. The User Territory feature grants visibility to Service Resource records that are members of the territory, allowing for proper resource allocation and scheduling.

C. Work Orders
Work Orders are the core definition of the work to be performed. Since the sharing model is private, a user wouldn't naturally see a Work Order they don't own. The User Territory feature shares Work Orders associated with the territory so that all relevant users (dispatchers and local managers) can view and track the status of the jobs in their area.

D. Resource Absences
Effective scheduling requires knowing when a technician is not available. Resource Absences are shared with users in the User Territory to ensure dispatchers don't accidentally schedule appointments during a technician’s time off, medical leave, or meetings.

🔴 Incorrect Answers
A. Accounts
While Work Orders are often related to Accounts, the Field Service User Territory feature does not automatically grant access to the Account record itself. Access to Accounts is typically managed through standard Salesforce sharing rules, Account Teams, or by setting the Work Order's OWD to "Controlled by Parent" (which would require the user to have Account access first, rather than the other way around).

E. Work Types
Work Types function as templates (metadata-like records) rather than operational data. In almost all Salesforce configurations, Work Types have an OWD of Public Read Only or are accessible to all users with a Field Service license. They are not governed by the specific record-sharing logic of the User Territory feature because they do not contain sensitive customer or schedule data.

📖 References
Salesforce Help: Limit Access to Field Service Records
Salesforce Help: How Service Territory Sharing Works
Trailhead: Field Service Security and Sharing

Explanation:

Why D is correct
When travel times between appointments are consistently underestimated, the biggest levers in Field Service are the routing method and the speed assumptions used to calculate travel duration:
Street-Level Routing (SLR) uses real road networks (instead of straight-line/aerial estimates), which produces more realistic travel times and reduces underestimation that causes cascading delays.
Default Travel Speed (and related routing preferences) directly affects calculated travel time—if it’s set too high, the system will calculate travel times that are too short. Salesforce routing setup explicitly includes Travel Speed Unit and Default Travel Speed as routing calculation inputs.

Why the other options are wrong
A. Minimum grade, default operating hour ❌
These relate to skills/requirements and operating hours, not travel-time math.
B. Estimated travel time, minimize travel ❌
“Minimize travel” is a routing preference, but it won’t fix systematic underestimation caused by aerial routing or incorrect speed assumptions.
C. Travel speed unit, actual travel time ❌
“Actual Travel Time” is something technicians can enter/record for reporting, but it’s not the primary lever to improve calculated travel-time accuracy between appointments.