Free Salesforce Advanced Field Service Accredited Professional Practice Test Questions

Explanation

In Salesforce Field Service, Work Rules are the building blocks of a Scheduling Policy and determine how the optimization engine matches Service Appointments (or Work Orders) to Service Resources. When a customer wants contractors excluded from optimization runs, the consultant needs a rule that filters resources based on a true/false attribute. A Match Boolean Work Rule does exactly this — it compares a boolean field on the Service Resource record (for example, a custom field like `Is Contractor__c` or `Exclude from Optimization__c`) against a defined true/false value and only allows a match when the condition is satisfied. By setting the rule to match only when the boolean equals `false` (i.e., the resource is not a contractor), contractors are filtered out before the optimization engine ever evaluates candidate resources. Because the rule is added to the Scheduling Policy that governs the relevant Work Orders and Service Appointments, contractors are never considered during optimization runs. This makes option D the correct answer.

Why the other options are incorrect

A. Create 'Count Rule' Work Rule and include it in the Scheduling Policy
– A Count Rule limits the number of Service Appointments or Work Orders that can be assigned to a resource within a given time period (for example, a maximum of five per day). It controls workload volume and does not evaluate any true/false attribute of the resource, so it cannot be used to exclude contractors from optimization.

B. Create 'Match Field' Work Rule and include it in the Scheduling Policy
– A Match Field Work Rule ensures that a field on the Service Appointment or Work Order equals a corresponding field on the Service Resource (for example, matching Service Territory or Skill). It is designed to align shared attributes between work and resources, not to filter resources based on a simple boolean flag, so it is not the appropriate rule type for excluding contractors.

C. Create 'Extended Match' Work Rule and include it in the Scheduling Policy
– An Extended Match Work Rule compares a field on the Service Appointment to a field on a related object (for example, an Account field versus a Resource field). It is intended for more complex, indirect matching scenarios and is not used to perform the straightforward boolean exclusion that this requirement demands.

Reference

Salesforce Help: Field Service Work Rules — Match Boolean Work Rule. Salesforce Help: Scheduling Policies and Work Rules (Field Service). Salesforce Trailhead: Field Service Scheduling module — Work Rules and Scheduling Policies.

Explanation

In Salesforce Field Service, the requirement is to ensure that only technicians holding the relevant security badge are selected for repair jobs in government buildings. This is a matching problem — the scheduling engine must compare an attribute on the work (the Account or Work Order indicating a security badge is required) against an attribute on the Service Resource (whether the technician holds that badge). Two Work Rule types can accomplish this depending on how the data is modeled.

A Match BooleanWork Rule works when the security badge requirement is represented as a boolean (true/false) field. For example, if the Service Resource has a field such as `Has Security Badge__c` and the Work Order or Account has a corresponding boolean field indicating a badge is required, the Match Boolean rule ensures that only resources where the boolean condition is satisfied are matched. This directly enforces the requirement.

An Extended Match Work Rule works when the badge information lives on a related object rather than directly on the Service Appointment or Service Resource. Extended Match compares a field on the Service Appointment to a field on a related object (for example, a field on the Account or on a related Badge object) against a field on the Service Resource. This allows the consultant to model the security badge requirement through a related record and still enforce the match during scheduling.

Because both rule types can enforce the badge-matching requirement depending on the data model chosen, both B and E are valid configuration options. This makes options B and E the correct answers.

Why the other options are incorrect

A. Create 'Resource Preferences' of Type 'Required' for Accounts that require specific Service Resources
– Resource Preferences are used to express a preference or requirement for a specific resource on a particular Service Appointment or Work Order, typically for continuity or customer preference reasons. They are not designed to enforce a skill or badge match across all jobs for an Account, and they do not scale as a scheduling policy mechanism for this type of attribute-based matching requirement.

C. Use time-phased skills in order to ensure that only resources with security badges can perform the job
– Time-phased skills allow a resource's skill level to change over time (for example, a skill that expires or becomes active on a certain date). While skills can be used for matching, time-phased skills are intended for scenarios where proficiency varies over time, not for enforcing a static security badge requirement. This is not the recommended configuration for the stated requirement.

D. Create an Apex Trigger that deletes 'Assigned Resources' that are not defined as 'Required Resources' for the Account
– Using an Apex Trigger to delete Assigned Resources is a reactive, code-based workaround rather than a declarative scheduling configuration. It would interfere with the scheduling engine's operation, could cause data integrity issues, and does not prevent incorrect assignments from being made in the first place. Salesforce best practice is to enforce matching rules declaratively through Work Rules in the Scheduling Policy.

Reference

Salesforce Help: Field Service Work Rules — Match Boolean Work Rule and Extended Match Work Rule. Salesforce Help: Scheduling Policies and Work Rules (Field Service). Salesforce Trailhead: Field Service Scheduling module — Work Rules and Scheduling Policies.

Explanation

The Dispatcher Console displays Service Appointment times based on the Scheduled Start and Scheduled End fields on the Service Appointment record. For the Dispatcher Console to reflect the actual times a field worker starts and completes work — and to free up white space on the Gantt when a worker finishes early — the Scheduled Start and Scheduled End fields themselves must be updated to match the actual times. Option D accomplishes this by using a Field Service Mobile flow that updates the Scheduled Start and Actual Start fields when the technician changes the Status to In Progress, and updates the Scheduled End and Actual End fields when the technician changes the Status to Completed. Because the Scheduled Start and Scheduled End fields are updated in real time, the Dispatcher Console immediately reflects the new times, and any early completion creates visible white space that dispatchers can fill with additional work. This makes option D the correct answer.

Why the other options are incorrect

A. Create two custom date/time fields to track the original scheduled times. Create a Field Service Mobile flow that will allow a field worker to update the 'Scheduled Start' and 'Actual Start' fields when they change the 'Status' to 'In Progress' and updates the 'Scheduled End' and 'Actual End' fields when they change the 'Status' to 'Completed'. Advise Universal Containers that there could be instances where the 'Dispatcher Console' will not update right away if the field worker is offline
– This option adds unnecessary complexity by creating custom fields to track original scheduled times when the requirement is simply to have the Dispatcher Console reflect actual times. While the offline caveat is a valid consideration, the added custom fields and the framing of the offline limitation make this a less clean and less correct approach than option D for the stated requirement.

B. Create a Service Appointment action for 'Check In' for the field worker to manually update the 'Status', 'Scheduled Start' and 'Actual Start' fields. Create another Service Appointment action for 'Check Out' for the field worker to manually update the 'Status', 'Scheduled End' and 'Actual End' fields
– This option requires the field worker to manually invoke separate Check In and Check Out actions, which adds friction and depends on the technician remembering to perform these actions. It does not automate the updates based on Status changes, making it less reliable and not the recommended approach.

C. Tell Universal Containers that it is not a best practice to change the 'Scheduled Start' and 'Scheduled End' fields. It would be good for Universal Containers to know what the original 'Scheduled Start' and the original 'Scheduled End' values were and compare them with the 'Actual Start' and 'Actual End' fields for reporting scheduling efficacy
– While it is true that Scheduled Start and Scheduled End are typically used for planning and Actual Start and Actual End for reporting, this option refuses the customer's requirement rather than solving it. The customer explicitly wants the Dispatcher Console to reflect actual times so that early completion creates visible white space. Option C does not meet the business requirement and is therefore incorrect.

Reference

Salesforce Help: Service Appointment Fields — Scheduled Start, Scheduled End, Actual Start, Actual End. Salesforce Help: Field Service Mobile Flows. Salesforce Help: Dispatcher Console — Gantt and White Space. Salesforce Trailhead: Field Service Mobile module — Mobile Flows and Status Transitions.

Explanation

In Salesforce Field Service, Assets support a parent-child relationship through the Related Assets related list, which allows a consultant to track replacement and upgrade chains in the field. The Related Assets related list on an Asset record displays two distinct perspectives: the Assets that replaced the current Asset (child Assets that point to the current Asset as their parent), and the Assets that the current Asset replaced (the parent Assets that the current Asset points to). By paying attention to both directions of this relationship, a consultant can fully trace the lifecycle of an Asset — understanding both what came before it (what it replaced) and what came after it (what replaced it). Because both perspectives reside on the same Related Assets related list, options A and B correctly identify the related list and the two directional views a consultant must examine. This makes options A and B the correct answers.

Why the other options are incorrect

C. Primary Assets related list as it shows Assets that the current Asset replaced
– There is no standard Primary Assets related list on the Asset object that serves this purpose. The replacement and upgrade relationships between Assets are tracked through the Related Assets related list, not a Primary Assets related list. This option incorrectly names the related list and therefore is not a valid answer.

D. Primary Assets related list as it shows Assets that replaced the current Asset
– As with option C, the Primary Assets related list is not the correct related list for tracking replacement and upgrade relationships. The relationships in both directions (what replaced the Asset and what the Asset replaced) are viewed through the Related Assets related list. This option is therefore incorrect.

Reference

Salesforce Help: Asset Object — Related Assets Related List. Salesforce Help: Field Service — Asset Hierarchy and Related Assets. Salesforce Trailhead: Field Service Asset Management module — Asset Relationships and Hierarchy.

Explanation

In Salesforce Field Service, mobile workers frequently need to capture and attach photos to Work Orders — for example, to document completed repairs, equipment condition, or proof of service. Salesforce provides two recommended, declarative best-practice approaches for this. First, an Upload Photo quick action can be added to the Work Order page layout, allowing the mobile worker to take or select a photo directly from the Field Service Mobile app and attach it to the Work Order with a single tap. Second, a Field Service Mobile flow can be configured with an image upload component, giving the mobile worker a guided, branded experience for capturing and attaching photos as part of a larger mobile workflow. Both approaches are declarative, mobile-optimized, and follow Salesforce best practices for photo capture in the field, making options A and B the correct answers.

Why the other options are incorrect

C. Edit the Work Order record through the SFS Mobile App and add the photo as an attachment
– While it is technically possible to edit a Work Order and manually add a photo as an attachment through the Field Service Mobile app, this is not considered a best practice. It is a manual, multi-step process that is slower for the mobile worker and does not leverage the purpose-built photo capture capabilities Salesforce provides. The declarative quick action or mobile flow approach is preferred.

D. Post the photo via the 'Feed' tab
– Posting a photo through the Feed tab (Chatter) attaches the photo to a feed post rather than directly to the Work Order as a proper attachment or file. This is not a best practice for capturing service documentation because it does not follow the structured attachment model, can be harder to report on, and is not the recommended way to associate a photo with a Work Order.

E. Use a quick action of type 'Attach File'
– An Attach File quick action allows a user to attach an existing file, but it is not the same as the purpose-built Upload Photo quick action that is optimized for mobile camera capture. The Upload Photo action is specifically designed for the field service mobile use case, whereas Attach File is a more generic action that does not provide the same streamlined photo capture experience.

Reference

Salesforce Help: Field Service Mobile — Upload Photo Quick Action. Salesforce Help: Field Service Mobile Flows — Image Upload Component. Salesforce Trailhead: Field Service Mobile module — Capturing Photos and Attachments.

Explanation

In Salesforce Field Service, In-Day Optimization is designed to continuously optimize a Service Territory's schedule during working hours by reassigning and rescheduling Service Appointments to improve efficiency. However, Service Appointments that are already underway — that is, in an 'In Progress' status — should generally not be moved to another Service Resource, because the technician is already on site performing the work. To prevent this, Salesforce provides a setting under Field Service Settings where administrators can specify which Service Appointment statuses are excluded from In-Day Optimization. If the 'In Progress' status has not been added to this exclusion list, the optimization engine will treat those appointments as movable and reassign them to other resources, which is exactly the behavior the dispatchers are observing. The correct troubleshooting step is therefore to review whether 'In Progress' is excluded from In-Day Optimization under Field Service Settings, making option C the correct answer.

Why the other options are incorrect

A. Check if the Scheduling Policy includes the 'Resource Availability' Work Rule
– The Resource Availability Work Rule controls whether a resource's availability (working hours, absences, and so on) is considered when matching work to resources. It has no bearing on whether an in-progress Service Appointment is eligible to be rescheduled by In-Day Optimization, so checking this rule would not explain or resolve the behavior described.

B. Review if the 'In Progress' status is configured in 'Status Transitions' under 'Field Service Settings'
– Status Transitions define the allowed paths a Service Appointment can take from one status to another (for example, from Dispatched to In Progress to Completed). While Status Transitions are important for controlling the lifecycle of a Service Appointment, they do not govern whether In-Day Optimization is allowed to reschedule an appointment that is already In Progress.

D. Check if the 'Optimization Request' status is 'In Progress'
– The Optimization Request status indicates the state of an optimization job itself (for example, whether an optimization run is pending, in progress, or completed). It describes the optimization process, not the Service Appointment status, and has no connection to why In-Progress appointments are being reassigned.

Reference

Salesforce Help: Field Service Settings — Exclude Service Appointment Statuses from In-Day Optimization. Salesforce Help: In-Day Optimization Overview. Salesforce Help: Status Transitions for Service Appointments. Salesforce Trailhead: Field Service Scheduling module — Optimization and Scheduling Policies.

Explanation

In Salesforce Field Service, when a Global Optimization run leaves a Service Appointment unscheduled even though white space appears to be available on the Gantt, the underlying cause is almost always a constraint imposed by the Scheduling Policy — such as a Work Rule, Service Objective, or resource matching requirement that the available resources do not satisfy. The fastest and most practical way for a dispatcher to surface the root cause is to manually drag the unscheduled Service Appointment onto the white space on the Gantt. When the dispatcher attempts the manual assignment, the Dispatcher Console evaluates the appointment against the Scheduling Policy in real time and displays the specific rule violations that prevent the assignment — for example, a missing skill match, a violated Work Rule, a Service Objective conflict, or a resource availability constraint. This immediate feedback identifies exactly which rule is blocking the scheduling, allowing the dispatcher or consultant to correct the configuration. This makes option A the correct answer.

Why the other options are incorrect

B. Click on the 'Appointment Booking' action on the appointment from the appointments list to identify which candidates are displayed
– While the Appointment Booking action can show candidate resources for an appointment, it is a candidate-selection tool rather than a root-cause diagnostic tool. It does not clearly surface the specific rule violations that prevented the optimization engine from scheduling the appointment, so it would not reliably identify the root cause described in the scenario.

C. Remove the Service Objective with the highest weight from the Scheduling Policy
– Removing a Service Objective is a destructive configuration change, not a troubleshooting step. It would alter the behavior of the Scheduling Policy for all future optimization runs and does not help identify why this particular Service Appointment was left unscheduled. A dispatcher should never modify the Scheduling Policy to diagnose a scheduling problem.

D. Check the 'In-Day Optimization' checkbox on the Scheduling Policy used in the previous run, and re-run the optimization request
– In-Day Optimization is a separate optimization mode intended for intra-day schedule adjustments, not a diagnostic setting for Global Optimization. Enabling it and re-running the optimization would not reveal why the appointment was unscheduled and could produce different, unintended results.

Reference

Salesforce Help: Dispatcher Console — Manually Scheduling Service Appointments and Viewing Rule Violations. Salesforce Help: Global Optimization and Scheduling Policies. Salesforce Help: Work Rules and Service Objectives in Scheduling Policies. Salesforce Trailhead: Field Service Scheduling module — Troubleshooting Optimization Results.

Explanation

In Salesforce Field Service, when a new product is installed to replace an obsolete product at a customer site, the relationship between the old Asset and the new Asset needs to be tracked for reporting and lifecycle purposes. The Asset Relationship object is specifically designed to model these connections between Assets — it allows an admin to create a relationship record that links one Asset to another, such as linking the obsolete Asset to the replacement Asset that superseded it. By configuring Asset Relationship records, the admin enables reporting that shows which product was replaced, which product replaced it, and, because each Asset is associated with an Account, the customer for which the upgrade was performed. This makes the Asset Relationship object the correct choice, and option C is the correct answer.

Why the other options are incorrect

A. Child Asset
– "Child Asset" is not a standalone standard object used to track replacement relationships between Assets. Asset hierarchy and replacement relationships are modeled through the Asset Relationship object (and viewed through the Related Assets related list), not through a Child Asset object.

B. Asset Warranty
– The Asset Warranty object is used to track warranty terms and coverage associated with an Asset, such as warranty start and end dates and terms. It has nothing to do with recording that one product replaced another, so it cannot support the upgrade-tracking requirement.

D. Maintenance Asset
– The Maintenance Asset object is used in the context of maintenance plans and maintenance work to associate Assets with maintenance activities. It does not model the replacement or upgrade relationship between an obsolete Asset and a new Asset, so it is not the correct object for this requirement.

Reference

Salesforce Help: Asset Relationship Object — Tracking Relationships Between Assets. Salesforce Help: Field Service — Asset Hierarchy and Related Assets. Salesforce Help: Asset Object — Related Assets Related List. Salesforce Trailhead: Field Service Asset Management module — Asset Relationships and Hierarchy.

Explanation

In Salesforce Field Service, the Service Territory Member record links a Service Resource to a Service Territory, and it includes an address field that represents the resource's starting and ending location for the day. This address is used by the optimization and scheduling engines to calculate travel time and route the technician's day. In this scenario, technicians must begin their day at the service center to pick up inventory and end their day at the service center to return unused or damaged parts. Because the technician's paid working time starts and ends at the service center — and travel between home and the service center is at the technician's own expense — the Service Territory Member address must be set to the address of the service center the technician is assigned to. Configuring it this way ensures that the scheduler correctly calculates travel time from the service center to the first appointment and from the last appointment back to the service center, and that the technician's workday is modeled accurately for optimization, routing, and reporting. This makes option C the correct answer.

Why the other options are incorrect

A. Use the technician's home address
– Using the technician's home address would model the technician's day as starting and ending at home. This is incorrect because the technician's paid workday begins and ends at the service center, and travel between home and the service center is explicitly at the technician's own expense. Using the home address would produce inaccurate travel times and misrepresent the working day in optimization.

B. Use the customer's address
– The customer's address is the destination for a Service Appointment, not the technician's starting or ending location. Using a customer address as the Service Territory Member address would incorrectly model the technician as starting and ending the day at a customer site, which does not match the described process.

D. Use the address of the first appointment of the day
– The first appointment of the day is a destination, not the technician's base location. The technician must first travel to the service center to pick up inventory, so the day cannot be modeled as starting at the first appointment. Using the first appointment's address would omit the service center leg entirely and distort travel time calculations.

Reference

Salesforce Help: Service Territory Member — Address and Starting/Ending Location. Salesforce Help: Field Service — Service Territories and Service Territory Members. Salesforce Help: Scheduling and Optimization — Travel Time Calculation. Salesforce Trailhead: Field Service Scheduling module — Service Territories and Resource Configuration.

Explanation

When a Service Territory's schedule is full of routine maintenance appointments while urgent repair jobs remain unscheduled, the dispatcher needs to make room for the urgent work by allowing the optimization engine to rearrange the existing schedule. First, the dispatcher should check the Scheduling Priority of both the repair and maintenance Service Appointments (option B). Scheduling Priority is the field the optimizer uses to determine which appointments take precedence when the schedule is constrained; if the urgent repairs have a higher priority than the routine maintenance, the optimizer will know to fit them in by moving lower-priority work. Second, the dispatcher should ensure that the maintenance Service Appointments are not Pinned (option D). Pinned appointments are locked in place and cannot be moved by the optimizer; if maintenance appointments are pinned, the optimizer has no flexibility to rearrange the schedule and make room for the urgent repairs. Third, once priorities are set correctly and appointments are unpinned, the dispatcher should run Global Optimization (option C) for the territory schedule for the next week. Global Optimization will reschedule the entire territory's appointments according to the Scheduling Policy, priorities, and constraints, fitting the urgent repair jobs into the schedule while pushing lower-priority maintenance work to available slots. Together, these three actions allow the dispatcher to free up capacity and schedule the urgent repairs, making options B, C, and D the correct answers.

Why the other options are incorrect

A. Manually update the 'Assigned Resource' on each of the urgent repairs
– Manually assigning a resource to each urgent repair bypasses the optimization engine and does not address the underlying problem that the schedule is full. Manual assignment may create conflicts, ignore travel time and work rules, and is not a scalable or best-practice approach when the goal is to rebalance the entire territory schedule.

E. Invoke 'Resource Schedule Optimization' for each Service Resource in the Service Territory
– Resource Schedule Optimization optimizes the schedule of a single Service Resource at a time, not the territory as a whole. Running it resource by resource is inefficient and does not coordinate the territory-wide reshuffling needed to fit urgent repairs while preserving the overall schedule. Global Optimization is the correct tool for a territory-wide rebalance.

Reference

Salesforce Help: Scheduling Priority on Service Appointments. Salesforce Help: Pinned Service Appointments and Optimization. Salesforce Help: Global Optimization — Optimizing a Service Territory Schedule. Salesforce Trailhead: Field Service Scheduling module — Optimization, Priorities, and Pinning.