FS-Con-101 Practice Questions

Salesforce Field Service provides two primary mechanisms to ensure specific technicians are assigned or prevented from being assigned to a job based on customer feedback.

1. Resource Preferences (B): This is the most direct method. A Resource Preference record can be created on the customer's Account or a specific Work Order. This record links a Service Resource (technician) and sets a preference type of 'Required', 'Preferred', or 'Excluded'. The scheduling engine then honors these preferences for all future work for that account.

2. Work Rules (A): The 'Required Resources' and 'Excluded Resources' Work Rules can be added to a scheduling policy. These rules check for specific resources listed on the Service Appointment or its parent Work Order. An automated process, triggered by customer feedback, could populate these required or excluded resource fields on the work record, thereby enforcing the customer's preference during scheduling.

C. Configure and add excluded and required resource business objectives to scheduling policies.

This is incorrect because 'Required' and 'Excluded' are enforced by Work Rules (hard constraints), not Service Objectives (soft constraints used for grading candidates).

D. Configure customer preferences on the Service Resource record.

This is incorrect as the data model is reversed. Customer preferences are stored on the customer's record (Account) or the job (Work Order), not on the technician's (Service Resource) record.

1. Salesforce Field Service Administrator Guide, "Set Up Resource Preferences": "To make sure that the right agent is assigned to a customer, create resource preferences. You can identify required, preferred, or excluded agents for a work order, work order line item, or account. Resource preferences are respected by the scheduling optimizer." (This directly supports option B).

2. Salesforce Field Service Administrator Guide, "Standard Work Rules for Field Service", Section: "Required Resources": "The Required Resources work rule ensures that a service appointment is assigned only to service resources listed in the Required Resources field on the appointment’s parent record." (This directly supports option A).

3. Salesforce Field Service Administrator Guide, "Standard Work Rules for Field Service", Section: "Excluded Resources": "The Excluded Resources work rule prevents a service appointment from being assigned to any service resource listed in the Excluded Resources field on the appointment’s parent record." (This further supports option A).

4. Salesforce Field Service Administrator Guide, "Create Scheduling Policies for Field Service", Section: "Work Rules vs. Service Objectives": This section clarifies the distinction: "Work rules enforce constraints... For example, the Match Skills rule ensures that a service resource has the required skills to perform a task. Service objectives are scheduling goals... For example, the Minimize Travel service objective encourages the optimizer to choose the resource with the shortest travel time." (This confirms why option C is incorrect).

When implementing SLAs for Work Orders, several components are critical. Entitlements define the specific support level a customer is eligible for and can be associated with Accounts, Contacts, or Assets. Business Hours are crucial as they define the timeframes during which SLAs are active, ensuring calculations for compliance are based on operational hours. Finally, Milestones are the core mechanism for tracking SLA adherence, with statuses like 'Compliant' and 'Violated' providing clear visibility into performance against the agreed service levels. These three elements form the foundation of SLA management in Field Service.

While it's true that Milestones apply to Work Orders and not Work Order Line Items, the other three options represent the foundational components required to build the SLA process itself.

Standard SLA functionality is configured declaratively using Entitlement Processes and Milestones; it does not require custom Apex triggers for its basic operation.

1. Salesforce Help. (2023). Set Up Entitlement Management. Salesforce Inc. Section: "Entitlement Management Setup Checklist". This guide outlines the relationship between Entitlements, Accounts/Assets, and Milestones.

2. Salesforce Help. (2023). Milestones. Salesforce Inc. Section: "How Do Milestones Work?". This document explains the role of Business Hours and milestone statuses in tracking compliance.

3. Salesforce Help. (2023). Guidelines for Working with Entitlements and Milestones on Work Orders. Salesforce Inc. This confirms that entitlements can be linked to assets and accounts for work orders.

The requirement specifies a "Work Order Line Item card" to view "work progress," which implies a custom user interface element capable of summarizing or graphically representing the status of line items. A standard related list (Option C) only displays records in a list format. The most appropriate and powerful solution is to create a custom Lightning Component (specifically, a Lightning Web Component) that aggregates data from the Work Order Line Items to display progress (e.g., as a percentage or status bar). This component can then be exposed in the Field Service mobile app, providing technicians with a purpose-built, at-a-glance view directly within their workflow.

A. Create a custom Visuaiforce page and add an extemal link in the Salesforce Field Service mobile app to view the page in the mobile browser.

Visualforce is not the modern framework for the Field Service mobile UI, and launching an external browser link creates a disjointed, non-native user experience.

B. Create a Report Chart that summarizes wk Order Line Items andadd 2 link to the Service Appointment layout.

This solution navigates the user away from the primary record to a separate report, failing to provide an integrated "card" view within the context of the Work Order.

C. Add the Work Order Line Items related list to the Work Order page layout and assign the layout to the Technician’s profile.

This makes the line items visible but as a standard list of records. It does not create a specialized "card" that explicitly visualizes overall work progress as implied by the requirement.

1. Salesforce Field Service Developer Guide, "Lightning Web Components for Field Service": This section details the use of Lightning Web Components (LWCs) to create custom functionality and user interfaces within the Field Service mobile app. It states, "Create custom Lightning web components to customize the user interface and create your own functionality for the Field Service mobile app." This directly supports using a custom component for a specific UI need like a progress card.

2. Salesforce Help, "Add a Lightning Component to a Record Page": The process of making a custom component visible involves adding it to a Lightning record page. For the mobile app, this component would be added to the relevant page layout that is enabled for mobile, such as the Work Order page. The documentation outlines how custom components can be surfaced on record pages.

3. Trailhead, "Field Service Mobile App Customization", Unit: "Extend the App with Lightning Components": This module explicitly teaches how to build and deploy custom Lightning Web Components to enhance the Field Service mobile app's functionality, which aligns perfectly with the solution described in option D. It demonstrates that for requirements beyond standard layouts, custom components are the sanctioned approach.

To track an asset swap, a relationship must be established between the original asset and its replacement. The standard Salesforce Field Service object for this purpose is the AssetRelationship. A consultant should configure this object by defining appropriate RelationshipType picklist values (e.g., "Replaced By," "Replacement For"). To make this relationship visible to users on the asset's record page, the "Related Asset" related list must be added to the Asset page layout. This combination directly addresses the requirement to track the asset's lifecycle concerning swaps by linking the distinct asset records involved.

A. Field history tracking shows changes to a single asset's fields, but it cannot create or display a link between two separate asset records, which is essential for a swap.

B. While the "Related Asset" related list is correct, the Product Request object is used for inventory management (requesting parts for a job), not for defining the relationship between the old and new assets.

D. Field history tracking is insufficient for tracking a relationship between two different assets. The core of the solution is the relationship object and its visibility on the page layout.

---

1. Salesforce Help Documentation: Track Relationships Between Assets

Content: This official guide explicitly states, "Create asset relationships to track how assets are related to each other. For example, if a part of your customer’s boiler is replaced, you can create a relationship between the original boiler asset and the new part asset." It also instructs administrators to add the "Related Assets" related list to asset page layouts to view these relationships.

Reference: Salesforce Help, Article Number 000337189, "Track Relationships Between Assets."

2. Salesforce Field Service Developer Guide: AssetRelationship

Content: The developer guide defines the AssetRelationship object as the junction object that "Represents the relationship between two assets." It contains key fields like AssetId, RelatedAssetId, and RelationshipType, which are fundamental to configuring and establishing the link between a swapped-out asset and its replacement.

Reference: Salesforce Field Service Developer Guide, Object Reference for Salesforce and Lightning Platform, "AssetRelationship."

3. Salesforce Help Documentation: Field History Tracking

Content: This documentation explains that Field History Tracking retains a history of changes to the values in specific fields on a record. It does not describe any capability to link one record to another, confirming why options A and D are incorrect for tracking a swap relationship.

Reference: Salesforce Help, Article Number 000329434, "Field History Tracking."

Salesforce Field Service provides two primary methods for creating skills. The Field Service Guided Setup wizard offers a streamlined, step-by-step process ideal for initial implementation, which includes creating skills and assigning them to service resources. Alternatively, for more granular control or ongoing maintenance, an administrator can use the standard Salesforce Setup menu. This manual approach involves navigating to the Skills object to create skill records and then assigning them to individual Service Resource records through the Service Resource Skills related list. Both are valid and officially documented methods.

A. Create the work skills using the FSL Lightning Web Component. Assign the skills to Service Resources. Add the skill to Work Types and Work Orders.

"FSL Lightning Web Component" is not a standard tool for creating skills; this is done via Guided Setup or the standard Setup menu.

C. Create the work skills using the FSL Lightning Managed Package wizard. Assign the skills to Service Resources. Add the skill to Work Types and Work Orders.

The correct term for the setup tool is the "Field Service Guided Setup," not the "FSL Lightning Managed Package wizard."

1. Salesforce Official Documentation, Set Up Skills in Field Service: "You can create skills in Setup or using the Field Service Guided Setup. After you create skills, assign them to service resources." This statement directly validates both the Guided Setup (Option B) and the standard Setup (Option D) approaches.

2. Salesforce Official Documentation, Field Service Guided Setup: The documentation outlines the steps within the wizard, which include "Create Skills" and "Create Service Resources." In the "Create Service Resources" step, the guide explicitly details how to assign the previously created skills to the resources, confirming the process described in Option B.

3. Salesforce Official Documentation, Create Service Resources for Field Service: This document details the manual process. Under the section "Assign Skills to Service Resources," it states: "In the Service Resource Skills related list, click New," confirming the manual assignment process which is part of the standard Setup approach (Option D).

The Products Consumed object is the standard mechanism in Salesforce Field Service for a technician to record the specific parts and quantities used from their mobile inventory (van stock) to complete a work order. Creating a Product Consumed record automatically deducts the item from the technician's Product Item records, ensuring inventory levels are accurately reflected. This action is performed after the work is done and is distinct from planning which parts are needed (Products Required).

A. Products Required: This related list is used for planning which parts are needed for a job before the work is performed, not for recording actual consumption.

B. Product Transfer: This object tracks the movement of inventory between two locations (e.g., warehouse to van), not the consumption of a part on a job.

D. Price Book: A Price Book contains the prices of products and services. It is used for billing and quoting, not for tracking inventory consumption.

1. Salesforce Help, "Track Products Consumed on Work Orders." This document states, "Create products consumed to track the parts that were used to complete a work order... When a product is consumed from a location, the quantity of the corresponding product item is updated."

2. Salesforce Field Service Developer Guide, "Object: ProductConsumed." The documentation describes this object as representing "a product that was used in a work order or work order line item."

In Salesforce Field Service, inventory requirements for a job are tracked using the Product Required object. This object specifies the parts or materials needed to complete the work. To ensure technicians have the necessary materials, Product Required records can be associated at two levels:

1. Work Order: For simpler jobs, required products can be linked directly to the parent Work Order.

2. Work Order Line Item: For more complex jobs with multiple distinct tasks, it is best practice to link required products to individual Work Order Line Items. This provides a more granular and accurate list of materials needed for each specific task within the overall job.

B. Products Required for Service Appointments: Inventory requirements are defined by the scope of work (the Work Order or its Line Items), not the scheduled visit (Service Appointment).

D. Products Required for Service Resources: This is incorrect. A Service Resource's inventory (e.g., van stock) is tracked as a location, but the requirements for a specific job are tied to that job's Work Order, not the technician.

1. Salesforce Field Service Developer Guide, ProductRequired Object: The official documentation for the ProductRequired object shows that its ParentId field is a polymorphic key that can reference a WorkOrder or a WorkOrderLineItem. This confirms that products required are linked to these two objects.

Source: Salesforce Developers, "ProductRequired," Object Reference for the Salesforce Platform.

2. Salesforce Help, "Guidelines for Using Products Required": This document explicitly states, "Products required can be added to work orders and work order line items to indicate the parts that are needed to complete the work."

Source: Salesforce Help, "Guidelines for Using Products Required," Field Service Documentation.

3. Salesforce Help, "Field Service Data Model": The official data model diagram for Field Service illustrates the relationships between objects. It shows a direct relationship from ProductRequired to both WorkOrder and WorkOrderLineItem, but not to ServiceAppointment or ServiceResource for tracking job requirements.

Source: Salesforce Help, "Field Service Data Model," Field Service Documentation.

The Products Consumed object is specifically designed to track the parts and products used from inventory to complete a work order. Each ProductConsumed record links a specific product (Product2) to a Work Order or Work Order Line Item and includes the quantity used. Therefore, creating a report on the Products Consumed object is the most direct and accurate method to track the volume of products installed during a specific timeframe, as it captures the transactional data of product usage.

A report on the Work Order object: This would show completed work but not the specific products or quantities installed without creating a complex report type.

A report on the Asset object: Assets represent a customer's installed products. Reporting on them shows the current state, not the volume installed within a specific period.

A report on the Product Request object: This tracks products that are needed for a job, not the products that were actually consumed or installed.

Salesforce Help, (2023). "Track and Report on Field Service Inventory". This document clarifies, "When a part is used to complete a work order, a product consumed record is created... You can run reports on products consumed to keep a close eye on your inventory levels."

Salesforce Field Service Data Model Guide, (2023). The schema diagram shows ProductConsumed as the junction object linking Product2 and WorkOrder to track consumption.

In Salesforce Field Service, a Service Appointment represents a single, schedulable visit or block of work. To accommodate two technicians working on the same overall job but at different times, it is necessary to create two distinct Service Appointments. Each appointment can be independently scheduled according to its own time constraints and assigned to a different technician. Both Service Appointments would be related to the same parent Work Order, ensuring they are tracked as part of the same job while allowing for scheduling flexibility.

B. Create one Service Appointment and add two Required Resources.

This approach, known as a crew, requires both resources to be scheduled for the same time slot, which contradicts the requirement that they can be onsite at different times.

C. Create one Service Appointment and schedule two Resources.

Assigning two resources to a single Service Appointment forces them into the same schedule for that appointment, which does not allow for work at different times.

D. Create two Service Appointments and set the Early Start to the Start Time of the first Service Appointment.

While creating two appointments is correct, this option describes an incorrect method for managing their relationship. Dependencies (e.g., Start After Finish) are the proper way to link appointments, not manually setting the Early Start field.

1. Salesforce Help: Manage Complex Work in Field Service.

Section: "Service Appointment Dependencies"

Content: "When a job requires multiple steps or visits, create a service appointment for each one. Then, use dependencies to link the appointments." This official documentation directly supports creating multiple appointments for a single job that has distinct work components or timing, which is the case when two technicians work at different times.

2. Salesforce Field Service Developer Guide.

Section: "Object Relationships"

Content: The data model shows that a WorkOrder can have multiple child ServiceAppointment records. This one-to-many relationship is designed to support scenarios where a single job (Work Order) requires multiple separate site visits or work phases (Service Appointments) that need to be scheduled independently.

3. Salesforce Help: Guidelines for Creating Service Crews.

Section: "When to Use Service Crews"

Content: "A service crew is a group of two or more service resources that are assigned to a service appointment as a single unit... Use crews when a job requires more than one person working together at the same time." This clarifies that crews (multiple resources on one appointment) are for concurrent work, making options B and C incorrect for this scenario.

This data model correctly represents the standard hierarchy in Salesforce Field Service. The Work Order serves as the parent record for the overall job—the preventative maintenance. Work Order Line Items are child records of the Work Order, perfectly suited for breaking down the job into individual, trackable steps or operations as required by the Standard Operating Procedure (SOP). Each line item can have its own status and notes. Finally, the Service Appointment is generated from the Work Order to schedule the single visit where the technician will perform the work defined in the work order and its line items.

B: This incorrectly assigns the Service Appointment to represent the overall maintenance job and the Work Order to represent the visit. The Work Order defines the work, while the Service Appointment defines the schedule.

C: This incorrectly suggests using Service Appointments to represent individual operations. Service Appointments are for scheduling visits, not for itemizing tasks within a single job. Work Order Line Items serve this purpose.

D: This inverts the standard data model. A Work Order Line Item is a child of a Work Order and represents a sub-task, not the entire maintenance job. The Work Order is the parent record.

1. Salesforce Help Documentation, "The Field Service Data Model": This document outlines the core objects and their relationships. It states, "Work orders represent work to be performed for a customer... Work order line items are a way to represent specific tasks that a mobile worker must perform to complete a work order... Service appointments represent service visits to customers." This directly supports the hierarchy in option A.

Reference: Salesforce Help, Field Service Basics, "The Field Service Data Model".

2. Salesforce Help Documentation, "Guidelines for Creating Work Orders for Field Service": This guide clarifies the purpose of work orders and line items. It specifies, "A work order represents a task to be performed... To break down the work into smaller steps, add work order line items to work orders." This confirms that operations should be represented by Work Order Line Items.

Reference: Salesforce Help, Field Service Core Features, Work Orders, "Guidelines for Creating Work Orders for Field Service".

3. Salesforce Developer Guide, "Field Service Object Model": The entity-relationship diagrams in this guide visually confirm that WorkOrder is the central object. Both WorkOrderLineItem and ServiceAppointment are shown as child objects with a master-detail or lookup relationship to the WorkOrder, validating the structure proposed in answer A.

Reference: Salesforce Developer Documentation, Field Service Developer Guide, "Object Model".