Field-Service-Consultant Practice Test Questions

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, 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:

The Sort by Average Utilization option in the Resources Tab of the Dispatcher Console Gantt chart allows dispatchers to sort field resources based on their average utilization percentage. Utilization is a key metric that measures how much time a resource spends on scheduled service appointments compared to their total available working hours. By sorting this way, Universal Containers can quickly identify resources who are underutilized (need more appointments) or overutilized (need fewer appointments/have capacity issues), thus enabling better workload balancing.

Why other options are incorrect

A. Select Date Resolution on the Hours Tab:
This option changes the time granularity displayed on the Gantt chart (e.g., from hourly view to daily view) and does not directly provide information about individual resource workloads or utilization metrics.

B. Select Travel Time and Breaks as skills on the Skills Tab:
Skills are used for matching resource expertise to job requirements. This option would filter resources based on whether they have "Travel Time" or "Breaks" as a skill, which are not standard skills in the FSL context, and wouldn't provide information on resource workload.

C. Select Hours, Absences and Overtime on the Utilization Tab:
This combination of selections is not a standard filter or view option in the FSL Gantt's utilization feature. The utilization tracking itself helps with this, but the specific action described in the correct answer is the proper way to use the Gantt interface to identify under/overutilized resources.

Explanation

Universal Containers needs a single preventive maintenance job on one asset, but also wants each SOP operation tracked independently so technicians can enter notes and update status as they progress—while still completing everything in one visit.
This maps cleanly to the standard Field Service model:

Work Order = the overall maintenance job (tracks the work to be performed for the customer/asset).
Work Order Line Items = the individual SOP operations/subtasks under the work order (each line item can be progressed and tracked separately).
Service Appointment = the single scheduled visit (the dispatchable/schedulable “appointment” that occurs once, tied to the parent record—typically a Work Order or Work Order Line Item).

Why the other options are incorrect
B: A Service Appointment represents the visit, not the overall preventive maintenance job.
C: Service Appointments aren’t meant to represent each operation; that’s what Work Order Line Items (subtasks) are for.
D: Reverses the hierarchy—Work Order Line Item is a child/subtask of Work Order, not the parent job.

References
Trailhead – Generate Work Orders for Efficient Service Management (Work Order = work to be performed; Work Order Line Items = more granular tasks)
Field Service Developer Guide – WorkOrderLineItem (“A work order line item is a child record of a work order… a specific subtask”)

Explanation:

This question tests your understanding of the Maintenance Plan object in Field Service Lightning, specifically the settings that control when automatically generated work orders are created.
Let’s break down the requirement: Inspections must happen three times per year (frequency) and the work orders for these visits must be created 14 days before the next scheduled inspection date. This "14 days before" is the critical configuration detail.
In a Maintenance Plan, the Generation Timeframe and Generation Horizon are the two fields that work together to define this lead time:

Generation Timeframe (Answer C):
This is the unit of time (e.g., Days, Weeks) used to calculate how far in advance to create the work order.
Generation Horizon (Answer D):
This is the number that, when combined with the Timeframe, specifies the exact lead time. In this case, you would set Generation Horizon = 14 and Generation Timeframe = Days.
Together, a setting of "14 Days" ensures the system generates the work order exactly 14 calendar days before the calculated due date (the "next suggested inspection date").

Why the other options are incorrect:
A. Associate a Required Skill called Site Visit to a Maintenance Plan: While you can assign required skills to a Maintenance Plan to ensure the right technician is scheduled, this does nothing to control when the work orders are generated. It addresses resource qualification, not scheduling timing.
B. Associate a Work Type called Site Visit to a Maintenance Plan: This is almost a prerequisite—you must associate a Work Type (which defines duration, skills, etc.) to a Maintenance Plan to generate Work Orders. However, like option A, this does not solve the requirement of creating those work orders 14 days in advance. It defines what is generated, not when.

Reference:
Salesforce Help Article: "Create Maintenance Plans in Field Service." The section on Generating Work Orders Automatically explains the use of the Generation Horizon and Generation Timeframe fields to determine how many days (or weeks) before the due date a work order should be created.

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:

The requirement is for technicians to view work progress through the Work Order Line Item card in the Salesforce Field Service mobile app. In Field Service Lightning (FSL), the mobile app displays information based on page layouts and related lists. By adding the Work Order Line Items related list to the Work Order page layout, Salesforce automatically exposes this data in the mobile app as a card. Assigning this layout to the Technician profile ensures that technicians specifically see the card when accessing Work Orders in the mobile app.

Option A (Visualforce page) is incorrect because Visualforce pages are not optimized for the Field Service mobile app and would require technicians to leave the app to view progress. This breaks the native mobile experience.
Option B (Report Chart) is incorrect because charts only summarize data and do not provide interactive record-level detail for Work Order Line Items. Technicians need to see and update specific line items, not just aggregated information.
Option D (Custom Lightning Component) is unnecessary because Salesforce already provides native support for Work Order Line Item cards. Custom development adds complexity without solving the requirement more effectively.

Therefore, the most efficient and Salesforce-recommended solution is Option C, which uses native configuration to meet the requirement without customization.

Reference:
Salesforce Help: Work Order Line Items
Salesforce Help: Field Service Mobile App Configuration

Exam Tip:
When you see “Technicians need to view progress in the mobile app,” always think page layout + related list configuration. Salesforce exam questions often try to distract you with custom development options (Visualforce, Lightning Components), but the correct answer is usually native configuration.

Explanation:

A Custom Gantt Filter is the standard and most effective way to filter Service Appointments within the Dispatcher Console (the Gantt). This feature allows users to define specific criteria—such as "Status = Emergency" or "Work Type = Emergency"—and save that view.

Crucially, Gantt Filters can be kept private, shared with specific Public Groups, or shared with individual users. By creating a filter for emergency work and sharing it only with the "Dispatchers" public group, the consultant ensures that only those users see that specific view on their Gantt.

🔴 Incorrect Answers
B. Custom Lightning Component
While a custom Lightning Component could technically be built to display data, it represents significant over-engineering. Salesforce Field Service provides out-of-the-box functionality (Gantt Filters) specifically designed for this purpose. Consultants should always prioritize "Clicks not Code" to ensure easier maintenance and upgrades.
C. Custom Report in a Private Report Folder
A report is a static or semi-real-time view of data, but it is not an operational tool for dispatchers. Dispatchers need to interact with work orders (drag and drop, schedule, dispatch) in real-time. Furthermore, a "Private" report folder would only be visible to the person who created it, not a group of dispatchers, unless shared via a shared folder—but even then, it doesn't solve the need for a "view" within the Dispatcher Console.
D. Custom List View
Standard Salesforce List Views are used on the Service Appointments tab, but they do not control the visibility of appointments on the Field Service Dispatcher Console (Gantt). While a dispatcher could use a list view, the prompt implies a "view" within their primary workspace (the Gantt), where custom filters are the native mechanism for visibility.

📖 References
Salesforce Help: Filter the Service Appointment List in the Dispatcher Console
Salesforce Help: Create and Share Custom Gantt Filters
Trailhead: Manage the Dispatcher Console

Explanation:

Salesforce Field Service uses a feature called Complex Work to manage multi-staged jobs or projects that require dependencies between different appointments.
Two Service Appointments: Each stage of the job is represented by its own Service Appointment record. This allows each stage to have its own assigned resource, duration, and status.
Time Dependency (Start After Finish): By relating these appointments and setting a Time Dependency, you can enforce a specific sequence. In this case, a "Start After Finish" dependency ensures that the second appointment can only be scheduled once the first is completed.
Same Day/Same Resource (Optional): While not explicitly required by the prompt, the Complex Work model also allows you to specify if these appointments must happen on the same day or be performed by the same resource.

Why other options are incorrect
B & D: Using a single Service Appointment for two different resources or a combined duration does not allow for independent tracking of "stages." It treats the work as one continuous block rather than a sequential process where one stage must finish before the next begins.
C: Simply scheduling them to the same resource does not programmatically enforce the "Start After Finish" dependency. Without the Time Dependency setting, a dispatcher or optimization engine could accidentally schedule the second appointment before the first one is completed.

Explanation:

In Field Service, technicians request replacement parts using a Product Request. Product Requests are created from (and related to) the work that needs the part—typically the Work Order (or, if you’re tracking parts at a more granular level, the Work Order Line Item).
Since Work Order Line Item isn’t an option here, the correct choice is Work Order.
Product Requests appear in the Product Requests related list on the related Work Order or Work Order Line Item, which is how technicians/dispatchers track parts needed for upcoming work.
Work Orders are the standard record that tracks work to be performed and commonly serve as the parent context for related execution records (appointments, line items, parts requests).

Why the other options are incorrect
A. Work Types — Work Types are templates; you don’t request specific inventory for a specific job from a template.
C. Service Appointment — Service Appointments represent the scheduled visit; part requests are tied to the work (WO/WOLI), not the visit record.
D. Service Report — Service Reports document outcomes; they’re not the object used to request inventory.

References:
Salesforce Help — Request Inventory in Field Service (Product Request appears on the related Work Order or Work Order Line Item)
Salesforce Help — Field Service Objects (Work Order tracks work to be performed; relationship context)