Explanation:

This question focuses on the process for a technician to order parts from an inventory location to their current location.

A Product Request is the master object that represents the entire request to transfer inventory from one location (e.g., a central warehouse) to another (e.g., the technician's van or a local depot). It contains header-level information like the source and destination locations.

Product Request Line Items are the child records of the Product Request. Each line item specifies the exact product and the quantity being requested. A single Product Request can contain multiple line items for different products.

This two-step process (create the header record, then add line items) is the standard and supported way to request parts in Salesforce Field Service inventory management.

🔴 Option A is incorrect: A Shipment is created to represent the fulfillment of a transfer or order (like a Product Request) once it is being acted upon, not the initial request itself.

🔴 Option B is incorrect: Product Consumed is used to record parts that have been used on a Work Order, reducing on-hand inventory. It is not used to request new parts.

🔴 Option D is incorrect: A Work Order Line Item defines a product needed to complete a job. While it can be the reason for a parts request, it is not the mechanism for creating the request itself. The request process is handled through the dedicated Product Request objects.

🔗 Reference:
Salesforce Help: "Request Inventory Using the Mobile App"
Key Concept: The Product Request object is the formal way to request a transfer of inventory, and it contains Product Request Line Items for the specific products needed.

Explanation:

The Asset object in Salesforce supports Field History Tracking, which allows administrators to enable tracking on key fields such as Status, Location (or related fields like Account, Contact, or custom location fields), and others relevant to the asset's lifecycle. Once enabled (up to 20 fields per object), changes to these fields are recorded in the Asset History related list, showing the old/new values, who made the change, and when.

This provides a quick, auditable view of location and status changes over time for a specific component (asset) in the customer's install base, directly meeting the requirement for service managers to identify lifecycle changes efficiently.

Why not the other options?

A: A Work Order related list on Assets shows associated service history (e.g., repairs), but not direct changes to the asset's own location or status fields over its lifecycle.

B: Custom fields could store current or snapshot data but do not inherently track historical changes (who/when/old vs. new) without additional reporting or automation.

D: A Product related list links the asset to its base Product (e.g., model), but does not track lifecycle changes like location or status updates.

This is the standard Salesforce feature for auditing field changes on objects like Asset, as documented in Salesforce Help (e.g., "Enable Field History Tracking" and related articles). It is commonly tested in the Field Service Consultant exam for asset management scenarios.

Explanation:

This question tests your understanding of configuring Required Products (parts) via Work Types to standardize what technicians need for a job, ensuring they have the correct equipment.

Analysis of Correct Answers:

A. Quantity and Unit of Measure are required when adding a Required Product: This is a configuration truth. When you add a product to the "Products Required" related list on a Work Type (or Work Order/WOLI), you must specify both the Quantity and the Unit of Measure (e.g., Each, Box, Meter). This is essential for accurate inventory planning and picking lists, ensuring the technician has the right amount of each part.

D. Work Types can be configured to include Required Products on Work Orders and Work Order Line Items: This is the primary method to meet the requirement. By adding Required Products to a Work Type, those products are automatically added to the Work Order (or Work Order Line Items) when a Work Order is created using that Work Type. This standardizes the parts list for every job of that category, reducing errors and ensuring technicians are dispatched with the correct, predefined equipment.

Why the other options are incorrect:

B. Validation Rules and Triggers created on the Work Order and Work Order Line Item objects are automatically recreated for Work Types: This is false. Work Types are separate objects. Validation rules and triggers are object-specific. A validation rule on the Work Order object does not automatically apply to the Work Type object, and vice versa. They must be created separately if needed.

C. Required Products must be added to both the Work Order and all Work Order Line Items: This is incorrect and inefficient. You do not need to add products to both levels; you choose the appropriate level. Typically, you add them to:
- The Work Order for parts needed for the overall job.
- Individual Work Order Line Items for parts specific to a particular task or asset.
Adding the same product to both levels would create duplicates. The configuration is either/or, not both/and, based on the job's structure.

Reference:
Salesforce Help: "Add Products to Work Types" – This article confirms that you can add products to Work Types and that they are copied to the resulting Work Orders/Line Items. It shows the Quantity and Unit of Measure fields as part of the configuration.

The use of Work Types as templates for required products is a best practice for standardizing job preparation and ensuring technicians have what they need, which directly addresses the business requirement.

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:

A. Auto-generate work orders with a 14-day generation horizon
To make sure each inspection visit is scheduled within 14 days of the inspection due date, UC should set the Maintenance Plan’s Generation Horizon (Days) = 14 (and use auto-generation). The generation horizon controls how many days before the next suggested maintenance date Salesforce generates the next work order(s). So with 14, the inspection work order is created 14 days before it’s due—giving dispatch/scheduling a defined window to plan the visit within that SLA window.
In other words:
the system creates the work early enough (14 days ahead) so it can be scheduled/assigned before it becomes late.

B. Associate a Work Type called “Site Visit” to the Maintenance Plan
A Maintenance Plan uses a Work Type as the template for the work it generates. Work Types standardize the job and can include things like estimated duration, required skills, products required, and instructions. That’s critical here because UC wants trained inspectors and a consistent inspection visit pattern.
By associating a “Site Visit” Work Type to the Maintenance Plan, UC can put the “trained inspector” requirement directly into the Work Type via Skill Requirements (e.g., “Inspector Certification”), and then scheduling can enforce qualification matching when assigning the appointment. Work types are explicitly used to standardize field service processes and can carry required skills.

Why the other options aren’t correct

C. Associate a required skill to the maintenance plan — Skills/Skill Requirements are natively associated to Work Types / Work Orders / Work Order Line Items (and then used for matching), not typically “attached to the maintenance plan” as the primary configuration approach tested; the recommended pattern is Work Type with skill requirements, inherited by generated work.

D. 14-day generation time frame — Generation Time Frame is about how far into the future Salesforce generates work orders as a batch (the span of future work to create). It’s not the “create it X days before due date” control—that’s Generation Horizon.