Explanation:

Adding one hour to the start and end times on the Service Territory Member's Operating Hours directly addresses the scheduling discrepancy caused by the time zone difference while maintaining data integrity across the system. This approach recognizes that Service Territory Members (technicians) have their own Operating Hours records that define when they are available to work, independent of the Service Territory's general time zone setting. Since the member is one hour behind the territory's time zone, their working hours effectively occur one hour later in absolute time (UTC) than what the territory's time zone would suggest. By adjusting the member's Operating Hours to start and end one hour later relative to the territory's time zone, the scheduling engine will correctly calculate availability and appointment times.

For example, if the Service Territory operates on Eastern Time (ET) and a technician in Central Time (CT, one hour behind) typically works 8 AM to 5 PM CT, their Operating Hours should be configured as 9 AM to 6 PM ET to reflect the same absolute working period. This method ensures that optimization runs, scheduling algorithms, and appointment timing all align correctly without requiring systemic time zone changes that could affect other users or processes.

Why Other Answers Are Incorrect

Option A (Add time to Service Territory hours):
Would incorrectly shift the entire territory's operational window rather than addressing the specific member's discrepancy. Changing the Service Territory's Operating Hours affects all members and appointments within that territory, potentially disrupting schedules for technicians who are in the correct time zone. This approach creates a cascading problem where properly aligned members now have incorrectly shifted schedules to accommodate one member's time zone difference.

Option B (Change time zone on user record):
Creates systemic issues beyond field service scheduling. The user's time zone setting in Salesforce affects their entire user experience—reports, dashboards, email timestamps, and all time-based calculations throughout Salesforce. Changing this to match the Service Territory would cause the technician to see all times in Salesforce incorrectly relative to their actual location, leading to confusion in scheduling personal activities, interpreting report timestamps, and coordinating with others. This approach solves one problem while creating many others.

Option D (Subtract time from Service Territory):
Suffers from the same fundamental issue as Option A but in the opposite direction. Adjusting the entire territory's Operating Hours to accommodate one member's time zone difference would incorrectly affect all other members and appointments. This approach assumes the territory should adjust to the member rather than properly configuring the member's availability within the territory's established time framework.

References:
Salesforce Field Service Time Zone Management documentation explains: "When Service Territory Members operate in different time zones than their Service Territory, adjust their individual Operating Hours to reflect their actual availability in the territory's time zone. This ensures accurate scheduling without affecting other users or system-wide time settings."

Explanation:

Why the Answer is Right
Universal Containers’ requirement has two parts: (1) deploy Knowledge to the field team and (2) ensure technicians can access those articles offline while using the Field Service mobile experience. In Salesforce Field Service, the supported, scalable pattern is to attach Knowledge articles to the work context records that technicians already download to their devices (Work Orders, Work Order Line Items, Service Appointments, etc.). Salesforce explicitly supports attaching Knowledge articles to Work Types, Work Orders, and Work Order Line Items so mobile workers can use job-specific instructions, specifications, and guidelines.

When you attach articles at the Work Type level, the configuration becomes reusable and consistent: every time an agent creates a Work Order (or WOLI) with that Work Type, the relevant Knowledge can be surfaced without requiring manual searching or ad-hoc linking. This is why Work Types are the best template-based lever for field enablement: configure once, apply repeatedly.

From an offline perspective, Field Service mobile is designed for technicians working with limited connectivity. The best way to support offline usage is to ensure the Knowledge content is contextually related to the records that are expected to be accessed in the field. Work Types help guarantee that relationship is established early (at creation time), increasing the chance the technician has the right article content available when they’re onsite. In other words, Work Type → Work Order inheritance/association makes Knowledge consistent and job-relevant, rather than depending on technicians to search in the moment.

So, option B most directly aligns to Salesforce’s intended configuration model: attach the right Knowledge articles to a Work Type so they’re automatically available in the job context that the mobile worker uses.

Why the Other Options Are Incorrect

A. Salesforce Mobile App with deep linking:
Deep linking only helps navigate between apps/records. It does not guarantee offline availability of Knowledge content. Offline access is driven by what is synced/cached in the Field Service mobile experience—not by navigation mechanics. Also, the standard Salesforce mobile app is not the primary offline-first tool for Field Service execution.

C. Custom Mobile App syncing articles:
This is unnecessary and high-risk. You would be rebuilding mobile sync logic, permissions, caching rules, and user experience patterns that Salesforce already provides. The exam almost always prefers a configuration-first, standard capability approach when it exists.

D. Workflow associating articles based on a picklist:
Workflow Rules are legacy and limited, and using automation to attach Knowledge dynamically is not the recommended first-line approach when Work Types already provide a clean, maintainable way to associate articles consistently. It also doesn’t inherently solve the offline requirement better than Work Types do.

References
Salesforce Help: View Knowledge Articles in the Field Service Mobile App (articles can be attached to work orders, work order line items, and work types).
Salesforce Help: Set Up Knowledge for Work Orders (attach articles to work orders/WOLIs/work types for field use).
Salesforce Help: Guidelines for Creating Work Types for Field Service (knowledge articles can be attached to work types and appear for derived records).

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