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)

Explanation:

Because NTO uses a private sharing model with Field Service User Territories, dispatchers get access to territory-related records through:

User Territory records that associate a User (dispatcher) to a Service Territory (so the dispatcher is “in” that territory for Field Service sharing).
The User Territory Sharing Job, which (once enabled/configured) calculates/applies the sharing based on those user territory assignments so the dispatcher can actually see the relevant records.
That’s why the right actions are create the user territory assignment + run/configure the sharing job.

Why the other options are incorrect
C. Assign a new user territory and add each of the assigned service resources — user territories are primarily for user-to-territory sharing. Dispatchers don’t gain access by adding service resources here; resources are handled via territory membership/assignment for scheduling, not dispatcher record visibility.
D. Add the resources assigned to the Service Territory's Member related list — this manages which resources work in the territory, but it doesn’t grant the dispatcher the sharing-based record access required in a private model.

References:
Limit Access to Field Service Records (describes using User Territory records + enabling/running the user territory scheduled/sharing job under Field Service Settings → Sharing → Scheduled Jobs)
Guidelines for Creating Service Territories for Field Service (explicitly notes Field Service sharing uses public groups, User Territory records, and the user territory scheduled job)
Salesforce Object Reference — UserTerritory (confirms the user-to-territory assignment record used for territory-based access)

Explanation:

This question tests your understanding of the inventory consumption and reconciliation process in Field Service Lightning, specifically from the mobile technician's perspective after a job is complete.

Let's break down the requirement:
The technician has already used parts from their van stock to complete a job. They need to record this usage (for customer billing and job history) and adjust their van's inventory downward to reflect that the parts are no longer in stock. This is a post-service consumption entry.

Why Products Consumed is the correct place:
Purpose: The Products Consumed related list on the Work Order is the designated object for recording parts that have already been used or installed during a service job. It is specifically for historical tracking and inventory deduction after consumption.
Mobile Workflow: From the Field Service Mobile app, when a technician completes a job, they have the direct option to record parts consumed. This action does two things:
- Creates a Product Consumed record linked to the Work Order, documenting what was used.
- Automatically reduces the quantity of the corresponding Product Item (the specific serialized/lotted inventory instance in their van or at the location), thereby "adjusting their van stock" as required.

Why the other options are incorrect:
A. The Product Item Transactions Related List on the Product Item: Product Item Transaction records are automatically generated by the system to form an audit trail whenever inventory moves or is consumed (e.g., when a Product Consumed record is saved). A technician does not manually create these; they are the result of the consumption process.
B. The Work Order Line Item associated with the completed Work Order: Work Order Line Items define the scope of work and planned parts required for the job. They are typically created before the job. Recording actual parts used after the fact should be done on the Products Consumed list to maintain a clear distinction between what was planned vs. what was actually consumed.
D. The Product Request Line Item associated with the Product Request: Product Request and Product Request Line Items are used to request parts to be moved to a location (like the technician's van) before a job. They are for planning and procurement, not for recording post-job consumption. Once the parts are in the van and used, the request is fulfilled, and consumption is recorded separately.

Reference:
Salesforce Help: "Add Products Consumed on the Work Order" – This article directly addresses the scenario: "After technicians complete work... they can add products consumed to the work order from the mobile app... When you add a product consumed, the product item's quantity on hand is automatically updated."
The core concept is the inventory flow: Product Request (plan) -> Product Transfer (move) -> Product Item (stock) -> Product Consumed (use/deduct). The technician's action in this question is the final step in this flow.

Explanation:

Call Center Agents act as intake users who respond to customer requests, create Work Orders or Service Appointments, and book appointments (often using features like the "Book Appointment" global action or Candidate Finder). They do not need full dispatcher access to the Gantt/Dispatcher Console or technician mobile features.
The appropriate permission set license for these agents is the FSL Agent License (historically called Field Service Agent or Call Center Rep License). This provides minimal, targeted permissions for creating and booking field service records without granting unnecessary access (e.g., scheduling optimization or admin configurations).

The other options are incorrect:
A. FSL Resource License: This is for Service Resources (technicians) to enable them as bookable resources and grant mobile app access.
B. FSL Admin License: This is for administrators configuring Field Service settings, bundles, or advanced features.
D. FSL Dispatcher License: This grants access to the Dispatcher Console, Gantt, and advanced scheduling tools—overkill for agents who only book initial appointments.
Note: In newer Salesforce orgs, some agent-specific permissions are included in the base Field Service Standard permission, but exam questions (and older implementations) reference the distinct FSL Agent License for this role.

Reference:
Older Field Service documentation and implementation guides mention the FSL Agent License/Permissions for call center scenarios.
Common in Salesforce Certified Field Service Consultant exam dumps and study materials for intake/agent roles in call centers.

Explanation:

Universal Containers needs to track progress, parts used, and time spent for each machine at a customer site. In Field Service Lightning (FSL), the best practice is to use Work Orders with Work Order Line Items (WOLIs):
A Work Order represents the overall job at the customer site.
Work Order Line Items break down the job into smaller tasks, each linked to a specific Asset (in this case, each machine).
Each WOLI can have its own Service Appointment, allowing technicians to track progress, parts consumed, and time spent per machine.
This structure provides granular visibility into work performed on each asset while keeping everything tied to the parent Work Order for reporting and billing.

Let’s eliminate the incorrect options:
Option A (Each Asset with a Service Appointment): Service Appointments represent scheduled work, but they don’t provide the detailed tracking of parts and time per machine. ❌
Option C (Work Orders with multiple Service Appointments linked to Assets): While Service Appointments can be linked to Assets, this approach lacks the granularity of Work Order Line Items for tracking parts and progress. ❌
Option D (Each Account with a Service Appointment): Accounts represent customers, not individual machines. This would not allow tracking at the asset level. ❌

Reference:
Salesforce Help: Work Orders and Work Order Line Items
Salesforce Help: Service Appointments

Exam Tip:
When the requirement involves tracking work at the asset level (machine-specific progress, parts, and time), the correct design is always Work Orders → Work Order Line Items → Service Appointments. This hierarchy ensures scalability and detailed reporting.

Explanation:

This model provides the perfect balance of granularity and operational efficiency:
Work Order (The Parent): Acts as the "header" for the preventative maintenance job on that specific asset. It holds the high-level information about the customer, the asset, and the overall maintenance goal.
Work Order Line Items (The Steps): Each "operation" or step of the SOP is created as an individual Work Order Line Item (WOLI). This allows the technician to:
- Update the Status of each specific task (e.g., "Inspected," "Cleaned," "Lubricated").
- Enter Notes or log parts used for that specific operation.
- Follow the SOP in a clear, sequential list.
Service Appointment (The Visit): Since the requirement is to complete the work in a single visit, a single Service Appointment is created for the parent Work Order. This ensures the dispatcher only has to schedule one block of time for the technician, even though the technician is performing multiple distinct operations inside that window.

🔴 Incorrect Answers
B. Service appointment to represent... preventative maintenance / Work order to represent the visit: This reverses the standard data model. In Salesforce, a Service Appointment is a child record used for scheduling; it cannot "parent" Work Order Line Items. The Work Order is always the record that defines the scope of work.
C. Service appointments to represent the different operations: If every SOP step (operation) had its own Service Appointment, the dispatcher’s Gantt chart would be cluttered with dozens of tiny appointments for a single job. This would make scheduling a "single visit" nearly impossible for the optimization engine and confusing for the technician.
D. Work order line item to represent the preventative maintenance: This is the opposite of best practice. A WOLI is a "line item" or sub-task. The "Preventative Maintenance" is the overall job, which should be the Work Order. Using a Work Order for each "operation" would result in a massive number of parent records for a single asset visit, making reporting and history tracking extremely difficult.

📖 References
Salesforce Help: Work Order Line Item Guidelines
Salesforce Help: Work Order and Service Appointment Relationships
Trailhead: Set Up Work Order Management

Explanation

In 2026, the Drip Feed mechanism remains the standard Salesforce Field Service feature designed specifically to prevent overwhelming technicians and to maintain schedule flexibility in high-change environments.

How it Works: When Drip Feed is enabled, the scheduling engine or dispatcher does not "mass dispatch" the entire day's schedule. Instead, it only dispatches the next appointment once the current one is completed or reaches a specific status.
Meeting the Requirement: This ensures that the technician sees only one job at a time (their current/next assignment) on the Field Service mobile app. If the schedule changes in the back office, the dispatcher can rearrange future jobs without the technician seeing "stale" or changing data until the job is actually dispatched to them.
Configuration: This is typically configured in Field Service Settings under the Dispatcher Console UI or via the Field Service Mobile Settings, where you can define how many appointments to "drip" at once (in this case, set to 1).

Why other options are incorrect:
A. Instruct the dispatcher: While this works in theory, it is a manual process prone to human error. It does not provide a scalable system-enforced solution.
B. Send Appointment Notifications: This setting controls how notifications are delivered to the device, not which records are actually synced and visible in the app's schedule view.
D. Auto dispatch: Standard auto-dispatch logic usually dispatches all appointments that meet certain criteria (like being scheduled within the next 24 hours). It does not natively restrict the technician's view to only a single record at a time without being used in conjunction with Drip Feed.

Reference:
For further details on implementing this, refer to the Salesforce Help: Dispatch Appointments Using Drip Feed.