Explanation:

Why the Answer is Correct
To visualize the planned travel route on the Dispatcher Console, the engine must calculate the actual path between appointments. Street-Level Routing (SLR) is the standard for high-accuracy route visualization. Unlike aerial routing, which calculates distance as a straight line, SLR uses real road data and speed limits.

When Street-Level Routing is enabled, the Dispatcher Console can display the map view with polyline routes connecting each Service Appointment in a technician’s shift. This allows the dispatcher to see exactly how the technician will navigate through the city, identifying potential travel inefficiencies or overlaps.

Why the Others Are Incorrect

A. Reports:
Reports show rows of data; they cannot provide a visual, geographical map of a route.

B. Dashboards:
Dashboards show charts and KPIs such as total travel time, but they don’t show the spatial route on a map.

D. Aerial Routing:
While this shows a route, it is a point-to-point straight line. It doesn’t reflect the planned travel route across actual streets, making it less accurate for a dispatcher’s visualization needs.

Reference:
Salesforce Help: Set Up Routing for Field Service

Explanation:

NTO wants reporting on Assets with their attributes, including hierarchical relationships. Salesforce supports asset hierarchies natively using the Parent Asset relationship and supporting fields like Root Asset (the top-level asset in the hierarchy). Salesforce documentation explicitly states that you create hierarchical relationships between assets using Parent Asset, and you can add or read the Root Asset field to give users context on the top-level item in the hierarchy.

The question is about reporting, not about visualization in a UI component. For reporting, the most direct approach is to use standard reports that include those relationship fields (Parent Asset and Root Asset). In many orgs, standard report types already support Assets and allow selecting these relationship fields, making custom report types unnecessary unless your org has unusual data model extensions. The exam pattern usually favors using standard capabilities when available, and Salesforce clearly provides the fields needed to represent the hierarchy in report rows (for example, show Parent Asset Name and Root Asset Name).

This meets the requirement because hierarchy can be represented in tabular reporting. Each asset row can show its parent and root, allowing rollups, grouping, and filtering (for example, show all assets under root asset X or show leaf assets by parent). It’s a reporting-friendly model and doesn’t require a specialized action or customization.

Why the Other Options Are Incorrect

A. Assets without Products report:
Doesn’t address hierarchy. It’s a specific diagnostic report concept (missing product link), not a hierarchy reporting approach.

C. Create custom reports:
Is unnecessary unless standard report types cannot access the needed fields. Since Parent Asset and Root Asset are standard asset fields intended for hierarchy context, the standard reporting approach is typically sufficient.

D. Enable and customize the View Asset Hierarchy action:
Is about visualizing the hierarchy (interactive navigation), not reporting. The requirement explicitly says “wants to report,” which is why the reporting solution using standard reports that reference hierarchy fields is the better match.

References
Salesforce Help: Create Asset Hierarchies (Parent Asset field)
Salesforce Help: Configure Asset Settings (Root Asset field guidance)
Salesforce Help: Asset Fields (Root Asset definition)

Explanation:

Drip Feed is the specific Field Service feature designed to control the flow of work to technicians. It allows administrators to set a limit on how many appointments are dispatched at once. In this case, NTO can configure the Drip Feed to dispatch 2 appointments. When the technician completes their current task, the engine automatically "drips" the next two into their "Dispatched" queue. This provides consistency across territories and prevents technicians from being overwhelmed by a full day's list while ensuring they always have their "next" work ready.

Why the Others Are Incorrect

A & B:
Workflow rules and triggers could technically update a status, but they are difficult to maintain and don't natively respect the complex scheduling logic and territory settings that the built-in Drip Feed feature handles.

D:
A scheduled job runs at specific times (for example, every hour). Drip Feed is event-based, meaning it reacts the moment a technician completes a job, which is much more efficient for field operations.

Reference:
Salesforce Help: Customize the Drip Feed

Explanation:

Work Types in Salesforce Field Service are templates that define the standard attributes of a job. They can include:

Estimated duration of the job.
Required skills for the technician.
Required products (parts or materials) needed to complete the job.

By configuring Work Types with the required products, every Work Order created from that Work Type will automatically list the correct parts. This ensures technicians know exactly what inventory is needed before heading to the customer site, reducing delays and improving first-time fix rates.

This approach is scalable and efficient because Work Types can be reused across similar jobs. For example, an “Installation” Work Type might always require a specific set of parts, while a “Break-Fix” Work Type might require another set. Linking products to Work Types ensures consistency, reduces manual data entry, and supports inventory planning.

Why the Other Options Are Incorrect

A. Ensure product items are available in inventory:
Inventory availability is important, but it does not automatically list products on Work Orders. It only ensures stock exists.

C. Add product fields to the Work Order layout:
Adding fields provides visibility but does not populate required products automatically.

D. Create a flow to add products to the Work Order:
While possible, this is a custom solution. Salesforce provides Work Types as the standard, out-of-the-box way to handle this requirement. Using flows adds unnecessary complexity.

Exam Tip
When the exam mentions ensuring parts are listed correctly on Work Orders, the answer is almost always Work Types with required products. Work Types are the native template mechanism for jobs.

References
Salesforce Help: Work Types
Trailhead: Field Service Work Types

Explanation:

Using Work Types to assign associated Articles to Work Orders leverages the native offline capabilities of Salesforce Field Service Mobile when combined with Knowledge article pinning. Here's how this approach provides reliable offline access:

Automatic Article Association:
When Work Types are configured with associated Knowledge articles, any Work Order created from that Work Type automatically inherits those article associations.

Offline Synchronization:
The Salesforce Field Service Mobile app can be configured to sync specific Knowledge articles for offline access. When articles are associated with a technician's assigned work orders, those articles are automatically downloaded to the mobile device during synchronization.

Contextual Relevance:
Articles associated via Work Types are inherently relevant to the work being performed. If a technician is working on an "HVAC Installation" work type, they'll have HVAC installation articles available offline, not irrelevant articles.

Automatic Updates:
When articles are updated, the mobile app can sync new versions during the next online synchronization, ensuring technicians always have current information.

This approach requires proper configuration of Knowledge article visibility, Field Service Mobile settings for offline sync, and Work Type setup, but once configured, it provides seamless offline access to relevant technical documentation without manual intervention.

Why Other Answers Are Incorrect

Option B (Workflow to associate Articles):
Creates unnecessary complexity and may not support offline access reliably. While a workflow could theoretically associate articles with work orders, this doesn't guarantee those articles will be synchronized to mobile devices for offline access. The Salesforce mobile offline synchronization works best with native relationships and configurations, not custom automation.

Option C (Salesforce mobile app with deep linking):
Requires internet connectivity to access articles since deep linking typically opens online content. While the Salesforce mobile app supports offline functionality, deep linking to specific content generally requires network access to retrieve that content, making it unreliable for field technicians who may be in areas with poor or no connectivity.

Option D (Custom mobile app):
Represents significant development effort for functionality that exists natively. Building a custom app to sync articles would require developing synchronization logic, conflict resolution, storage management, and user interface—all of which are already provided in Salesforce Field Service Mobile when properly configured with Work Types and Knowledge associations.

References:
Salesforce Knowledge and Field Service Mobile Integration Guide explains: "For offline Knowledge access, associate articles with Work Types. When technicians receive work orders based on those Work Types, the associated articles are automatically synchronized to their mobile devices for offline access during field work."