Free Practice Questions for Salesforce AP-209 Exam

Asset replacement and history in Salesforce are tracked using the Asset Relationship object.

Options A and B are correct. The Asset Relationship object links two assets together (e.g., Old Asset - > New Asset) with a relationship type like "Replacement" or "Upgrade." On the Asset page layout, this related list (often labeled "Asset Relationships" or "Related Assets") allows you to see the history in both directions:

Forward: See the new asset that replaced this asset (Option A).

Backward: See the old asset that this asset replaced (Option B).

Options C and D are incorrect. "Primary Assets" is typically a concept associated with Service Contracts (covering the main asset) or Entitlements, not the history of physical swaps/upgrades between asset records.

(Note: The provided PDF source likely contains an error marking D as correct. "Primary Assets" is not the standard location for replacement history.)

Optimization Insights is the dedicated Field Service feature that captures per-run metrics such as travel time saved, utilization, gap minimization, and unscheduled work, making it the standard way to evaluate Global Optimization quality.

Option B is correct. Enabling Optimization Insights records the before/after metrics for each optimization request — travel minutes, scheduled vs. unscheduled count, average gap, and other KPIs. The data is available on the Optimization Request object and can be reported on directly in Salesforce.

Option A is incorrect because the SFS Dashboard package is an older, less precise tool that does not capture per-run optimization data.

Option C is incorrect because the Dispatcher Console is an operational view, not an analytics surface.

Option D is incorrect because subscribing to an Analytics App is unnecessary overhead when a built-in feature exists.

Salesforce Field Service uses two distinct KPIs for service contracts: Availability and Reliability. The two differ in whether planned downtime (scheduled maintenance) is counted against the asset.

Option C is correct. Availability measures the proportion of expected uptime that the Asset was usable, excluding only unplanned downtime. Planned maintenance is expected and excluded from the calculation, so Availability = (expected uptime - unplanned downtime) / expected uptime.

Option D is partially right in form but mislabeled — Reliability is the metric that subtracts both planned and unplanned downtime: Reliability = (expected uptime - planned - unplanned downtime) / expected uptime. Mislabeling it as the Availability formula (Option A) is incorrect.

Option A is incorrect because that is the Reliability formula, not Availability.

Option B is incorrect because Asset Uptime is the numerator of these formulas, not a ratio of Availability divided by Reliability.

When running optimization (Global or In-Day), the engine is allowed to move any appointment that is not "Pinned."

Option C is correct. In Salesforce Field Service, you must explicitly define which statuses are considered Pinned (immovable) during optimization. This is configured in Field Service Settings > Optimization > Logic . If the 'In Progress' status is not selected in the "Pinned Statuses" list, the optimization engine sees that appointment as movable. To improve the schedule, it might unassign the current tech and assign a different one, even though the tech is already on-site.

Ensuring 'In Progress' is "excluded from optimization logic" (Pinned) forces the engine to schedule around that appointment rather than moving it.

Option B refers to "Status Transitions," which controls the lifecycle flow (e.g., New - > Scheduled - > In Progress) but does not control the scheduling engine's permission to move the job.

This question addresses the trade-off between Customer Experience and Schedule Optimization.

Reducing the arrival window (e.g., from 4 hours to 2 hours) is a common strategy to improve customer service. Customers prefer shorter wait times and more precise appointments. However, a consultant must identify the technical impact of this business decision.

Option B is correct because it acknowledges the benefit (customer experience) while correctly identifying the risk. Smaller arrival windows serve as tighter constraints on the scheduling engine (Optimization). The engine has less "wiggle room" to shuffle appointments, which can lead to lower overall utilization or higher travel times.

Option C is incorrect because reducing the window decreases (restricts) flexibility for optimization, it does not increase it.

Options A and D suggest increasing the window to 8 hours. While this is great for the optimization engine (maximum flexibility), it is generally considered a poor customer experience to ask a prospect to wait all day (8 hours), contradicting the business goal of being "more competitive."

Offline capabilities are a critical feature of the Field Service mobile app.

Option E is correct: The fundamental behavior of the app is to "Prime" (download for offline use) the inventory associated with the Service Resource. This ensures that when a technician is in a basement with no signal, they can still view their van stock and consume parts (create Product Consumed records).

Option B is correct: Salesforce Field Service supports Multi-Location Inventory (e.g., a technician has a Van location and a Garage location). The app is capable of priming these additional locations so the tech can transfer stock between them. However, consultants must be aware of data volume limits (priming thousands of parts can slow down sync times), so configuration settings restrict how far back or how many items are synced.

Option D is incorrect because the app specifically allows for the consumption of parts while offline; the transactions sync back to the server once connectivity is restored.

The Dispatcher Console Map is the most efficient tool for geographic mass actions.

Option A is correct. Salesforce Field Service allows dispatchers to draw custom Map Polygons directly on the Gantt map. Once a polygon is drawn around the affected bushfire area, the dispatcher can right-click the polygon (or use the actions menu) to perform Mass Actions on all Service Appointments contained within that shape. "Unschedule," "Cancel," or "Flag" are standard bulk actions available in this context.

Option B (Reports/Data Loader) is too slow for an emergency response.

Option C (Optimization) would just move the appointments to later times, not cancel/unschedule them.

Option D (List View) is difficult because defining a "bushfire area" using text filters (City, Zip) is often inaccurate compared to drawing the precise boundary on a map.

Operating Hours model the working schedule, while Skills model what kind of work a resource is qualified to perform. Combining the two correctly meets both the availability and the work-type filter.

Option B is correct. Separate Operating Hours definitions allow you to model the different working hours and time zones used by internal vs. third-party resources. Using Skills to restrict the contractor resources to maintenance work is the standard way to enforce the type of work they should perform, by tagging the relevant Work Types (or Work Orders) with a 'Maintenance' skill that only the contractors hold.

Option A is incorrect because 'Designated Work' Time Slots are normally used to reserve specific blocks of time for a specific category of work — they are not designed to restrict a resource exclusively to maintenance across all its working hours.

Option C is incorrect because using only Shifts on top of a single Operating Hours record adds unnecessary complexity when the schedules differ structurally; separate Operating Hours definitions are cleaner.

Option D is incorrect for the same reason, and because it does not include any mechanism to restrict the contractors to maintenance work only.

Change management is one of the biggest risks on any Field Service implementation. When end-users are openly resistant, the consultant must adjust scope and approach rather than push more technology on top of the unrest.

Option C is correct. Investing in training reduces fear of the unknown and gives users confidence with the new tool. Phasing the rollout to a single Business Unit or Service Territory limits blast radius, lets the team build success stories, and turns early adopters into advocates for the broader rollout. This is a textbook change-management response.

Option A is incorrect because adding more new functionality (the Mobile App) to a team that is already overwhelmed will increase resistance, not reduce it.

Option B is incorrect because outsourcing the work does not address the user adoption problem and may further demoralize the existing staff.

Option D is incorrect because adding more automation does not solve cultural resistance; users need to understand and trust the system before automation will be embraced.

Resource Absence is a flexible object that supports custom values, but it has specific behavior on the SFS Mobile App and in the scheduling engine that admins must understand.

Option B is correct. The SFS Mobile App creates Resource Absence records using the default record type. To ensure those absences are honored by Auto-Schedule and Global Optimization, the 'Non-Availability' record type must be the default — otherwise the engine ignores them.

Option D is correct. The standard 'Type' picklist on Resource Absence includes Vacation, Meeting, Training, and Medical out of the box. Admins can add custom values, but these are the seeded options.

Option E is correct. The SFS Mobile App's Profile tab includes an Absences section where Service Resources can view and create their own absences, which feeds directly into the Gantt and the optimizer.

Option A is incorrect because custom Type values do show on the Gantt; absences appear as colored bars on the resource row regardless of the Type value used.

Option C is incorrect because the optimizer considers all Resource Absence records with a Non-Availability record type, regardless of whether the Type value is standard or custom.