Explanation:

In Salesforce Field Service, the Asset object is used to represent products that customers own or use. Assets could be anything from machines, equipment, or devices installed at a customer’s location.

When a technician replaces a faulty or damaged Asset, Salesforce needs to capture the relationship between the old Asset and the new one. This is done through Asset Relationships, which allow you to track how Assets are connected.

On the Asset record page, you’ll find two special related lists:

➡️ Primary Assets related list: This shows the parent Assets that this Asset is a part of. For example, if a printer cartridge is part of a larger printer, the printer would appear as the Primary Asset.
➡️ Related Assets related list: This shows other Assets that are associated with the current Asset. For example, if a router is replaced with a newer model, the old and new routers are linked here so that history and replacements can be tracked.

When a Flow in the Field Service mobile app is used to replace an Asset, Salesforce automatically records this replacement as a relationship. This replacement can only be viewed on the Asset object, not on Work Orders or Service Appointments.

Why not the other options?

A (Only Primary Assets related list on Asset): This ignores the “Related Assets” list, so it’s incomplete.

B (Only Primary Assets on Work Order): Work Orders show which Asset work was done on, but they don’t manage replacement history.

C (Both lists on Work Order): Incorrect because replacement history is tied to Assets, not Work Orders.

Real-world Example:
Imagine a customer has a broken modem. The technician replaces it with a new modem. Salesforce will link the old and new modems in the Asset record, so the company knows exactly when and why the swap happened.

Reference: Salesforce Help: Asset Relationships

Explanation:

The Match Territory Work Rule is a standard configuration in Salesforce Field Service that ensures Service Appointments are only assigned to Service Resources belonging to the same Service Territory. When this rule is included in the Scheduling Policy, the optimization and dispatching engine will automatically filter out resources outside of the territory.

This is the most efficient and scalable way to enforce territory-based dispatching. It avoids manual intervention and ensures consistency across all appointments. By leveraging this rule, dispatchers can be confident that technicians are dispatched only within their assigned territories, which is critical for organizations that operate across multiple regions.

Why the Other Options Are Incorrect

B. Resource Availability Work Rule:
This rule ensures that resources are scheduled only when they are available (considering operating hours, breaks, and absences). It does not enforce territory restrictions.

C. Mark the Service Territory’s Resources as Required on the Service Appointments:
This would require manual configuration for each appointment, which is not scalable. It also does not dynamically enforce territory rules during optimization.

D. Ensure the Resource’s Address is in the same Territory:
Addresses are used for travel calculations, not territory assignment. Territory membership is managed through Service Territory Members, not addresses.

Exam Tip:
When the exam mentions restricting dispatch to the same Service Territory, the answer is always Match Territory Work Rule in the Scheduling Policy. Resource Availability is about time, not territory; Required Resources are too rigid; and addresses are irrelevant to territory logic.

References:
Salesforce Help: Scheduling Policies and Work Rules
Trailhead: Field Service Scheduling

Explanation:

Why the Answer is Right
The requirement is to ensure technicians using the Field Service mobile application can access relevant Knowledge articles while completing assigned work. The most reliable, context-driven configuration is to attach Knowledge articles directly to the work execution records: Work Orders and/or Work Order Line Items. Salesforce explicitly supports attaching Knowledge articles to work orders, work order line items, and work types to share specifications, instructions, and guidelines with the field team. When articles are attached to the work record, technicians don’t have to “guess” what to search for or navigate a broad knowledge base; they receive the right content in the context of the job they’re already performing.

This approach also reduces operational risk. Field work often happens in low-connectivity areas. When Knowledge is attached to the job record, it is far more likely to be available in the mobile experience that is optimized for field execution. Attaching at the Work Order Line Item level can be even more precise: if a work order has multiple tasks (inspection + replacement + calibration), each line item can carry the exact guidance needed for that task. This is a best practice for relevance because not every article should be shown on every job—only those that match the job’s component steps.

Additionally, attaching articles at the work order level is consistent with how agents and dispatchers collaborate: agents can attach the articles at creation time based on customer symptoms, product model, or service history, and dispatchers/techs see those articles without extra configuration.

Why the Other Options Are Incorrect

A. Quick action to search the Knowledge base:
Search actions rely on technicians finding the right content themselves and can be slower, inconsistent, and connectivity-dependent. It doesn’t ensure relevance; it merely provides access.

C. Update Service Appointment layout to include Articles related list:
Articles are associated primarily with work records (work order/WOLI/work type). Adding an Articles related list on Service Appointment doesn’t guarantee technicians see job-relevant Knowledge, and it doesn’t address the core “attach relevant articles to the work” pattern described in Salesforce guidance.

D. Add the Knowledge Lightning component to the Field Service mobile app:
A Lightning component may help browsing, but it still doesn’t guarantee relevance or ensure that the right articles are linked to the job context. Salesforce’s recommended method is attachment to work records, not “just show Knowledge UI.”

References:
Salesforce Help: Set Up Knowledge for Work Orders (attach articles to work orders/WOLIs/work types).
Salesforce Help: View Knowledge Articles in the Field Service Mobile App (supported attachment points).
Salesforce Help: Create Field Service Work Orders (mentions knowledge interaction in work order context).

Explanation:

Skill management is a two-part process: definition and assignment.

Guided Setup (B):
The Field Service Managed Package includes a Guided Setup tool. This is the "Consultant's best friend." It provides a streamlined interface to create skills, assign them to resources, and set skill levels all in one view.

Standard Setup (D):
Skills can also be managed through the standard Salesforce Setup menu. You define the Skill object records in Setup and then manually create Service Resource Skill records to link those skills to individual technicians. Both methods are standard and widely used.

Why the Others Are Incorrect

A:
There is no standard "FSL Lightning Web Component" dedicated solely to creating and assigning skills from scratch in the way Guided Setup does.

C:
While the Managed Package is used, the term "Managed Package Wizard" usually refers to the Guided Setup itself; however, Option B is the more accurate name for that feature.

Reference:
Salesforce Help: Set Up Skills for Field Service

Explanation:

Why These Are Correct
B. Work Type association:
Work Types define job templates. Associating a “Site Visit” Work Type ensures each inspection has consistent requirements.

D. Generation Horizon:
Defines how many days before the due date the Work Order is generated. Setting this to 14 days ensures inspections are created in advance.

Why the Other Options Are Incorrect
A. Required Skill:
Ensures qualified inspectors but does not generate Work Orders.
C. Generation Timeframe:
Defines how long Work Orders are generated into the future, not how far in advance.

References:
Salesforce Help: Maintenance Plans