Pass the Salesforce Accredited Professional Certification AP-209 Questions and answers with CertsForce

The Field Service Mobile Settings configuration controls the behavior of the mobile app (branding, location tracking, flows, etc.).

Option D is correct. To apply different settings to different groups of users, you must create multiple Field Service Mobile Settings records. You assign these settings records to specific User Profiles .

You would create one settings record with "Collect Service Resource Geolocation History" enabled (for the tracked users).

You would create a second settings record with it disabled (for the untracked users).

You then map the relevant Profiles to the appropriate Settings record.

Options A, B, and C imply global settings or non-existent tabs ("Mobile App Configuration" tab where you select users/profiles directly doesn't exist in the global settings in this manner; it is done via the specific Mobile Settings object assignments).

Mapping resources to specific Zip Codes (which are not necessarily Service Territories) is a common high-volume requirement.

Option A is correct. Creating a standard Service Territory for every postal code (Option D) creates a hierarchy that is too deep and hurts performance.

Instead, modeling "Zip Code Coverage" as a Custom Object (or data table) allows for a cleaner data model. You then use the Extended Match Work Rule . This rule is highly flexible; it can verify that the Zip Code on the Service Appointment matches a record in the Zip Codes Covered related list on the Service Resource. This supports optimization without bloating the Territory or Skill tables.

Option B (Match Fields) only works for 1-to-1 matching (e.g., The Resource has one zip field). It cannot easily handle a resource covering 50 different zip codes unless you use the custom object approach described in A.

Salesforce Field Service schedules Service Resources, not Assets. To bring physical equipment into the scheduling engine, the equipment must be modeled as a Service Resource so the engine can check its availability, capacity, and skills.

Option D is correct. To include cranes, excavators, or any other equipment in scheduling, ACME must create Service Resource records for them (typically with a 'Resource Type' such as 'Equipment'). These records consume Field Service licenses, and once configured they participate in the candidate evaluation, capacity, and optimization just like a human technician.

Option A is incorrect because there is no 'Use for Scheduling' Boolean on the Asset object; Assets and Service Resources are separate concepts.

Option B is incorrect because a lookup field does not make the Asset part of the scheduling engine — it is just a reference.

Option C is incorrect because the Dispatcher Console does not expose an 'Include Assets' toggle on the Schedule action.

Resource Preferences are supported on Work Order Line Items, which makes the parent/child Work Order pattern fully usable for jobs that require specific resources with specialized skills.

Option C is correct. Resource Preferences can be added directly to the Work Order Line Item, with type 'Required' or 'Preferred', referencing the Service Resource(s) qualified for the specialized work. The scheduling engine respects those preferences when picking candidates for the WOLI's Service Appointment.

Option A is incorrect because Resource Preferences are supported in Complex Work scenarios, including WOLI-based hierarchies.

Option B is incorrect because Resource Priority ranks all resources globally; it doesn't target specific resources for a specific Work Order Line Item.

Option D is incorrect because Resource Preferences are supported on WOLI out of the box and do not require redesigning the data model.

To model international workforces in Salesforce Field Service, specific objects handle geography, time, and exceptions.

Option B is correct.

Service Territories: Used to define the geographical areas (Countries/Regions). Crucially, the Time Zone is defined on the Service Territory record.

Operating Hours: Used to define the "Permitted Working Hours" (e.g., Mon-Fri, 9-5). These are assigned to the Service Territory or Service Territory Member.

Resource Absences: Used to model time off, such as public holidays or sick days, where the resource is unavailable. (Note: Holidays can also be linked directly to Operating Hours, but Resource Absences are the distinct records created on the Gantt).

Option A is incorrect because "Business Hours" is a Service Cloud (Support) object used for Case Entitlements, not Field Service scheduling. "Resource Capacity" is used for contractors (Capacity-Based Scheduling), not for defining standard working hours.

This scenario involves two distinct types of work (Installation vs. Training) with different durations and likely different skill requirements, but they are part of the same customer order.

Option C is correct.

Data Model: Using Work Order Line Items (WOLIs) is the best practice here. You create one WOLI for the "Installation" (linked to a Work Type that allows Multi-Day) and a separate WOLI for "Training" (linked to a different Work Type). This allows you to track the status and skills for each part separately.

Dependency: Using Complex Work (specifically a "Start After Finish" dependency) ensures the Training appointment cannot be scheduled until the Installation is complete.

Option A puts both Appointments on the same Work Order parent. While possible, it makes it harder to report on "Training" vs "Install" costs separately and limits the ability to use different Work Types for each appointment automatically.

Option B relies on manual updates or custom automation ("When scheduled, update..."), whereas Complex Work (Option C) handles the logic natively during optimization.

The Dispatcher Console (Gantt) allows admins to customize which fields are visible in various panels and tooltips using standard Salesforce Field Sets.

A is correct (Resource Absence): You can control what information appears when a dispatcher hovers over a non-availability block (e.g., "Sick Day," "Doctor's Appointment") by editing the field set on the Resource Absence object.

B is correct (Service Appointment): This is the most heavily customized object. You can configure field sets to control the columns in the Appointment List, the text shown on the Gantt bar, and the fields in the tooltip (hover).

C is correct (Service Resource): You can customize the resource list (left-hand side of the Gantt) to show fields like "Vehicle Type," "Skill Level," or "Phone Number" by editing the field set on the Service Resource object.

Options D and E: Service Territory and Assigned Resource do not have direct field sets that control the Dispatcher Console layout in the same way the primary transactional objects do.

This requires a balance of data accuracy (tracking the asset) and schedule accuracy (updating the duration).

Option D is correct because it uses Field Service Mobile Flows , which is the best practice for guiding technicians through complex processes.

Data: Creating a Work Order Line Item (WOLI) is the correct data model to track work done on a specific (secondary) Asset under the main Work Order.

Schedule: The flow can update the current Service Appointment's Duration and Scheduled End to reflect the reality that the tech will be there longer.

Automation: Triggering a "Scheduling Recipe" (now typically handled via Flows/Optimization services) ensures that if the appointment runs long, subsequent appointments for the day are automatically shifted (Reshuffled) to prevent overlapping/late arrivals.

Options A and C fail to update the schedule duration, meaning the tech will likely be late to their next job without the dispatcher knowing. Option B creates a second appointment, which is administratively heavy for "just looking at" another asset during the same visit.

This is the standard troubleshooting procedure for "Why wasn't this scheduled?".

Option A is correct. If there is white space, but the optimizer didn't use it, there is likely a Rule Violation (Hard Constraint) preventing it (e.g., The resource is missing a Skill, the Territory doesn't match, or the Travel Time is too long). Manually dragging the appointment to that specific spot on the Gantt triggers the rule validation logic, and the console will pop up a "Rule Violation" message telling you exactly which rule failed (e.g., "Match Skills Rule Violation").

Option B helps find valid slots, but it doesn't explain why the current white space is invalid.

Option C addresses scoring (Objectives), not hard constraints (Rules). If there was space, the objectives would just give it a low score, not prevent scheduling entirely (unless the score was 0, but Rule Violations are the more common culprit for unscheduled work).

This issue arises because Salesforce Field Service calculates availability by combining Operating Hours AND Shifts. If a user has Operating Hours of 9-5, they are fundamentally "Available" during that time. A Shift is typically used to add or extend availability (or define it if using specific settings), but standard Operating Hours often take precedence as the "Base."

Option A is correct. To have a resource's availability defined exclusively by variable Shifts, the best practice is to assign them a "Shell" or "Empty" Operating Hours record (one with zero time slots defined). With no base hours, the system looks only to the Shifts to determine when the resource is working. This ensures that if a Shift ends at 4 PM, the resource is truly unavailable at 5 PM.

Option B is administratively impossible (you cannot automate changing the STM Operating Hours record lookup daily without complex custom code, and it's not a standard practice).