Free Practice Questions for the Salesforce Field Service Lightning program FS-Con-101 Exam (2026 Updated)

The requirement is best implemented with a monthly Maintenance Plan with a 12-month generation timeframe and automatic generation disabled. Frequency of one month models the twelve monthly checkups, while a 12-month generation timeframe represents the annual horizon. Because the customer calls to initiate each visit, automatic Work Order generation should remain disabled and work can be generated manually when appropriate.

The consultant should distinguish recurrence from job definition. A Work Type describes how a recurring job is performed, while the Maintenance Plan determines when and how future work is generated. Work Order and Service Appointment generation methods then determine whether Assets are consolidated into one visit or separated into multiple jobs.

The alternatives address different parts of the Field Service model. Automatically generating each month would remove the intended customer-driven control, while a one-month generation timeframe would not represent the planned annual set as efficiently.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Configuring Maintenance Plans — Maintenance Plans; Frequency; Generation Timeframe; Auto-generate Work Orders.

The correct configuration is separate Work Orders or separate Work Order Line Items with their own Service Appointments. Independent handling requires each Asset ' s work to have an independently schedulable Service Appointment. This can be achieved with separate Work Orders and appointments or with one Work Order containing Asset-specific line items, each with its own appointment.

Good Work Order design also preserves the distinction between planned work and execution results. Products Required, requirements, and task structure should be established before service; Products Consumed, actual times, signatures, and completion statuses then record what actually happened in the field.

The alternatives address different parts of the Field Service model. A single parent-level appointment would combine the Assets into one scheduling unit and would not let each container ' s service be handled independently.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Work Orders — Assets; Work Orders; Work Order Line Items; independent appointments.

Root Work Order and Root Work Order Line Item for multilevel hierarchies is the appropriate Field Service design. Root fields are most valuable when both Work Orders and Work Order Line Items have more than one hierarchy level because they provide direct visibility to the top-level record without navigating through intermediate parents.

Good Work Order design also preserves the distinction between planned work and execution results. Products Required, requirements, and task structure should be established before service; Products Consumed, actual times, signatures, and completion statuses then record what actually happened in the field.

The alternatives address different parts of the Field Service model. With only a single hierarchy level, the immediate Parent fields already provide most of the relationship context and the Root fields add less value.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Work Orders — Work Order hierarchies; Work Order Line Item hierarchies; Root fields.

Customer First and Soft Boundaries is the appropriate Field Service design. Customer First emphasizes preferred resources and prompt service while still considering efficiency. Soft Boundaries applies similar customer-oriented objectives but permits appropriate resource sharing across territory boundaries, which can improve coverage.

Salesforce Field Service treats the Service Appointment as the primary unit of scheduling. Scheduling Policies combine Work Rules, which determine whether a resource or time slot is valid, with Service Objectives, which score valid alternatives against business priorities. The selected configuration therefore has to operate at the scheduling layer rather than merely changing descriptive fields on the parent Work Order.

The alternatives address different parts of the Field Service model. High Intensity prioritizes throughput during heavy demand, and Emergency Policy is designed for urgent emergency work rather than normal preferred-resource commitments.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Scheduling and Optimization — Standard Scheduling Policies; Customer First; Soft Boundaries.

the appointment owner and members of the relevant User Territory is the appropriate Field Service design. With private sharing, Field Service uses managed sharing and territory public groups. Once a Service Appointment is canceled, assigned-resource access is no longer the primary path; the owner and users with the appropriate User Territory access retain visibility.

Field Service access combines Salesforce object permissions with Field Service permission-set licenses and managed sharing. The correct design applies least privilege: technicians, agents, dispatchers, contractors, and administrators should receive only the capabilities required for their operational persona.

The alternatives address different parts of the Field Service model. Service Territory membership and Assigned Resources serve different scheduling and access functions; the cancelled state changes which automatic sharing paths remain applicable.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Permissions and Sharing — Private OWD; User Territories; Service Appointment sharing.

The requirement is best implemented with Arrival Window Start and Arrival Window End. Arrival windows are the customer-facing expectation for when a technician is expected to arrive. They provide a practical range while allowing dispatchers operational flexibility if travel or earlier appointments change during the day.

Operationally, the goal is to preserve schedule integrity while minimizing manual intervention. Field Service should be allowed to use the standard scheduling engine wherever possible so that resource availability, travel, appointment constraints, priorities, and territory context remain consistent across manual and automated scheduling actions.

The alternatives address different parts of the Field Service model. Scheduled Start and Scheduled End are internal scheduling values and may move as the schedule is optimized, so sharing them as hard customer commitments is usually inappropriate.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Scheduling and Optimization — Service Appointment arrival windows; customer communications.

The requirement is best implemented with a Capacity-Based Service Resource for the Contractor Manager. Capacity-based scheduling models an external provider as a pool of contracted work capacity rather than as named individual technicians. The Contractor Manager can represent the weekly 100-hour capacity and update the work after completion.

The Field Service resource model separates the person or workforce unit from the qualifications, territory memberships, capacity, absences, and crew relationships used by scheduling. A Service Resource can therefore be evaluated consistently by the scheduling engine without embedding workforce logic directly in Work Orders or Service Appointments.

The alternatives address different parts of the Field Service model. A Service Crew assumes known resources working together, while creating individual contractor technicians would add detail the stated operating model does not require.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Resources — Capacity-Based Service Resources; contractors; capacity scheduling.

For this scenario, Salesforce Field Service should use the Service Resource Priority field. Resource Priority gives the scheduler a standard numeric way to favor one qualified resource over another. Lower numeric values represent higher priority, so senior Tier 3 technicians should receive lower numbers than Tier 2 and Tier 1 technicians.

In scheduling design, it is important to distinguish eligibility from preference. Work Rules filter candidates that do not satisfy hard constraints such as territory, availability, skills, or boolean conditions, while Service Objectives rank the remaining options. Dispatcher Console actions then use that policy logic to place, move, or dispatch appointments in a controlled way.

The alternatives address different parts of the Field Service model. Relevance groups decide when rules or objectives apply, queues do not provide this candidate-ranking behavior, and a custom field alone has no scheduling effect unless tied into policy logic.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Scheduling and Optimization — Resource Priority Service Objective; candidate ranking.

The correct configuration is Service Territory Member. The Service Territory Member record links a Service Resource to the territory in which the resource works. That relationship is fundamental to territory-based scheduling and sharing calculations for appointments assigned to the resource.

Field Service access combines Salesforce object permissions with Field Service permission-set licenses and managed sharing. The correct design applies least privilege: technicians, agents, dispatchers, contractors, and administrators should receive only the capabilities required for their operational persona.

The alternatives address different parts of the Field Service model. User Territory links users such as dispatchers to territory access groups; it serves a different persona and sharing purpose than the resource-territory membership relationship.

This approach follows least-privilege design and keeps access changes maintainable as resources, territories, assignments, or user responsibilities change.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Permissions and Sharing — Service Territory Members; resource-territory sharing.

a parent Work Order with Asset-specific Work Order Line Items is the appropriate Field Service design. Work Order Line Items are the standard way to represent individual components, Assets, or tasks under one service engagement. Each line item can carry its own Asset, status, Work Type, products, skills, pricing, and appointment when needed.

Reusable configuration should be preferred over duplicating records or custom objects. Work Types can standardize duration, required skills, required products, and Knowledge, while the Work Order hierarchy and Work Order Line Item hierarchy are available when genuinely separate but related work must be represented.

The alternatives address different parts of the Field Service model. Separate parent Work Orders are only necessary when the work must have independent job lifecycles; Products Consumed records materials used, not the component-level work structure.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Work Orders — Work Orders; Work Order Line Items; Asset-level service tracking.

The requirement is best implemented with Case → Work Order → Service Appointment → Dispatch. The Case captures the inbound customer issue, the Work Order represents the onsite work, and the Service Appointment is the schedulable visit assigned and dispatched to a Service Resource. This is the standard service-to-field execution sequence.

The Field Service data model separates the service requirement from its individual tasks and visits. A Work Order represents the overall job, Work Order Line Items represent component-level or task-level work, and Service Appointments represent the scheduled field visits used to execute that work. Choosing the correct level preserves accurate history, pricing, inventory, and scheduling.

The alternatives address different parts of the Field Service model. Dispatching a Work Order directly or creating an appointment before the underlying work reverses the Field Service data model and does not provide the intended parent-child structure.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Work Orders — Cases; Work Orders; Service Appointments; dispatch lifecycle.

For this scenario, Salesforce Field Service should use Asset Relationships visible through Primary Assets and Related Assets. Asset Relationship records capture replacement, upgrade, and related lifecycle links between specific Assets. The relationships are viewed on the Asset through the Primary Assets and Related Assets related lists.

Asset relationships and hierarchy fields provide different views of the installed base. Parent and Root Asset fields model structural hierarchy, while Asset Relationship records can model replacement, upgrade, or other lifecycle relationships. Field History Tracking complements those relationships by auditing changes to selected Asset fields over time.

The alternatives address different parts of the Field Service model. Field History Tracking only audits field changes and Product Requests manage inventory demand; neither models the relationship between an old Asset and its replacement.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Assets — Asset Relationships; Primary Assets; Related Assets.

For this scenario, Salesforce Field Service should use different Service Resource Skill Levels. The contractors differ in repair expertise, so the Repair skill should be assigned with different proficiency levels. Skill Requirements can then express the level needed for the Work Type and scheduling can distinguish their qualifications.

Salesforce favors reusable resource metadata over one-off record manipulation. When resource qualifications and availability are modeled correctly, the same information can support candidate selection, optimization, dispatching, reporting, and mobile execution without duplicating logic on individual jobs.

The alternatives address different parts of the Field Service model. Capacity represents workload volume, Preferred Resource expresses a preference rather than expertise, and excluding the less experienced contractor would unnecessarily prevent all assignment.

This keeps the workforce model reusable across scheduling, dispatching, mobile execution, and reporting and avoids encoding resource logic in individual work records.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Resources — Service Resource Skills; Skill Levels; Skill Requirements.

the standard Service Report is the appropriate Field Service design. Service Reports are designed to summarize completed field work, include customer-facing details, capture signatures, generate a PDF, and be sent electronically. They are integrated directly into Field Service Mobile and the Work Order/Service Appointment lifecycle.

When comparing Salesforce Mobile with Field Service Mobile, the latter should be treated as an operational field-work client rather than a generic CRM client. Its offline capabilities, appointment-centric experience, signature/report functions, geolocation controls, and technician-specific actions are the features that should drive the configuration decision.

The alternatives address different parts of the Field Service model. A generic Work Order email template or analytical report does not provide the structured service-document and signature workflow, and custom automation is unnecessary.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Configuring Mobility — Service Reports; Service Report Templates; signatures; electronic delivery.

The correct configuration is Multi-Day Service Appointments. Use them when one body of work exceeds a resource ' s available working hours in a day or must continue across consecutive days, including nonworking periods such as weekends. The scheduler distributes the duration across eligible working periods.

Salesforce Field Service treats the Service Appointment as the primary unit of scheduling. Scheduling Policies combine Work Rules, which determine whether a resource or time slot is valid, with Service Objectives, which score valid alternatives against business priorities. The selected configuration therefore has to operate at the scheduling layer rather than merely changing descriptive fields on the parent Work Order.

The alternatives address different parts of the Field Service model. Jobs requiring separate stages by different resources are better represented as separate appointments with dependencies, while a recurring same-day pattern is not a multi-day appointment.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Scheduling and Optimization — Multi-Day Service Appointments; resource availability; complex work.

For this scenario, Salesforce Field Service should use Page Layouts. Field Service Mobile uses assigned layouts to determine which Work Order and Service Appointment fields and related information technicians see. Appropriate profile/record-type layout assignments therefore provide the standard way to simplify the mobile record view.

Field Service Mobile is designed for technicians working in changing connectivity conditions. Standard page layouts, quick actions, flows, Service Reports, Knowledge, and supported mobile extensions should be used before introducing custom Visualforce or bespoke components because the native features participate in synchronization, offline behavior, and the Field Service security model.

The alternatives address different parts of the Field Service model. Field Sets apply to specific configurable surfaces, Visualforce is custom development, and Mini-Page Layouts do not drive the normal Field Service Mobile record experience.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Configuring Mobility — Field Service Mobile; Page Layouts; technician record views.

The requirement is best implemented with Multi-Day Service Appointments. Use them when one body of work exceeds a resource ' s available working hours in a day or must continue across consecutive days, including nonworking periods such as weekends. The scheduler distributes the duration across eligible working periods.

Operationally, the goal is to preserve schedule integrity while minimizing manual intervention. Field Service should be allowed to use the standard scheduling engine wherever possible so that resource availability, travel, appointment constraints, priorities, and territory context remain consistent across manual and automated scheduling actions.

The alternatives address different parts of the Field Service model. Jobs requiring separate stages by different resources are better represented as separate appointments with dependencies, while a recurring same-day pattern is not a multi-day appointment.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Scheduling and Optimization — Multi-Day Service Appointments; resource availability; complex work.

The correct configuration is Products Required on the Work Type. A Work Type acts as a reusable template for recurring service. Adding standard parts to its Products Required related list lets those requirements flow to Work Orders or Work Order Line Items when the Work Type is applied.

Inventory design should also preserve pricing and traceability. Price Books and Price Book Entries supply commercial pricing, while serialized inventory gives unit-level identity when individual items must be tracked. Product Requests and Product Transfers manage replenishment and movement rather than the underlying job structure.

The alternatives address different parts of the Field Service model. Product Items show stock at a Location, and custom Flow or layout fields do not replace the standard reusable Products Required model.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Inventory — Work Types; Products Required; inventory planning.

For this scenario, Salesforce Field Service should use Emergency scheduling. Emergency scheduling is designed to insert urgent work into an active day, identify an appropriate nearby technician, and dispatch the appointment even when normal schedules are already occupied.

Operationally, the goal is to preserve schedule integrity while minimizing manual intervention. Field Service should be allowed to use the standard scheduling engine wherever possible so that resource availability, travel, appointment constraints, priorities, and territory context remain consistent across manual and automated scheduling actions.

The alternatives address different parts of the Field Service model. Get Candidates is a general candidate-evaluation action, Appointment Booking is aimed at finding bookable slots, and Fill-In Schedule uses gaps for nonurgent work rather than interrupting the plan for an emergency.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Scheduling and Optimization — Emergency scheduling; Dispatcher Console; urgent dispatch.

The requirement is best implemented with Cannot Complete plus a new Service Appointment on the same Work Order. The technician made the visit but could not perform the work because the customer was unavailable. Marking the original appointment Cannot Complete preserves the failed-visit history, and a new appointment records the follow-up visit under the same underlying Work Order.

The Field Service data model separates the service requirement from its individual tasks and visits. A Work Order represents the overall job, Work Order Line Items represent component-level or task-level work, and Service Appointments represent the scheduled field visits used to execute that work. Choosing the correct level preserves accurate history, pricing, inventory, and scheduling.

The alternatives address different parts of the Field Service model. In Progress would misstate the final outcome, Complete would imply successful service, and a new Work Order is unnecessary because the service requirement itself has not changed.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Work Orders — Service Appointment lifecycle; Cannot Complete; follow-up visits.

For this scenario, Salesforce Field Service should use the Reshuffle action. Reshuffle is designed to insert important work into an already populated schedule by moving lower-priority appointments to other times, days, or resources as allowed by the Scheduling Policy.

Salesforce Field Service treats the Service Appointment as the primary unit of scheduling. Scheduling Policies combine Work Rules, which determine whether a resource or time slot is valid, with Service Objectives, which score valid alternatives against business priorities. The selected configuration therefore has to operate at the scheduling layer rather than merely changing descriptive fields on the parent Work Order.

The alternatives address different parts of the Field Service model. A normal reschedule changes a selected appointment but does not provide the same schedule-wide rearrangement around the incoming high-priority work; custom Apex is unnecessary.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Scheduling and Optimization — Reshuffle; appointment priority; in-day schedule adjustment.

The requirement is best implemented with Drip Feed dispatch. Drip Feed controls how many future Service Appointments are released to each technician. Setting the quantity to the required number keeps the technician queue small and automatically dispatches the next eligible appointment as current work is completed, canceled, or cannot be completed.

In scheduling design, it is important to distinguish eligibility from preference. Work Rules filter candidates that do not satisfy hard constraints such as territory, availability, skills, or boolean conditions, while Service Objectives rank the remaining options. Dispatcher Console actions then use that policy logic to place, move, or dispatch appointments in a controlled way.

The alternatives address different parts of the Field Service model. Manual dispatch creates avoidable administrative work, while ordinary auto-dispatch does not by itself provide the same controlled queue depth and protection from frequent schedule changes.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Scheduling and Optimization — Drip Feed; automated dispatch; mobile appointment visibility.

The requirement is best implemented with Field Service automatic sharing for dispatched Service Appointments. With private OWD, enabling the Field Service setting to share dispatched appointments with assigned resources grants the technician access based on the Assigned Resource relationship and appointment lifecycle.

With private organization-wide defaults, Field Service can use automatic sharing, User Territories, territory public groups, and assignment relationships to expose the operational records needed by technicians and dispatchers. These sharing mechanisms are distinct from the permissions that control whether a user can configure Field Service or use a particular application capability.

The alternatives address different parts of the Field Service model. Changing ownership or maintaining custom sharing rules adds unnecessary automation, while User Territories are mainly used to give dispatchers and call-center users access to territory records.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Permissions and Sharing — Private OWD; automatic sharing; Assigned Resources.

For this scenario, Salesforce Field Service should use Operating Hours on the Account. The time restriction belongs to the customer, so Account Operating Hours are the correct representation of when service can be performed at that customer site. Scheduling can then respect the customer-specific availability window.

In scheduling design, it is important to distinguish eligibility from preference. Work Rules filter candidates that do not satisfy hard constraints such as territory, availability, skills, or boolean conditions, while Service Objectives rank the remaining options. Dispatcher Console actions then use that policy logic to place, move, or dispatch appointments in a controlled way.

The alternatives address different parts of the Field Service model. Service Territory and Service Territory Member Operating Hours describe resource availability; placing the restriction there would incorrectly constrain other customers or technicians.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Scheduling and Optimization — Account Operating Hours; customer availability; scheduling constraints.

The correct configuration is a customer-specific Price Book containing all relevant products. A Work Order uses one Price Book, so the customer-specific book should contain both negotiated-price products and ordinary products that may appear on the same Work Order. This preserves standard Product selection and pricing on Work Order Line Items.

The Field Service data model separates the service requirement from its individual tasks and visits. A Work Order represents the overall job, Work Order Line Items represent component-level or task-level work, and Service Appointments represent the scheduled field visits used to execute that work. Choosing the correct level preserves accurate history, pricing, inventory, and scheduling.

The alternatives address different parts of the Field Service model. A book containing only discounted items would make other required products unavailable through the normal pricing model, and a global book would not represent customer-specific negotiated prices.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Work Orders — Work Order pricing; customer Price Books; Price Book Entries.

the Reshuffle action is the appropriate Field Service design. Reshuffle is designed to insert important work into an already populated schedule by moving lower-priority appointments to other times, days, or resources as allowed by the Scheduling Policy.

Salesforce Field Service treats the Service Appointment as the primary unit of scheduling. Scheduling Policies combine Work Rules, which determine whether a resource or time slot is valid, with Service Objectives, which score valid alternatives against business priorities. The selected configuration therefore has to operate at the scheduling layer rather than merely changing descriptive fields on the parent Work Order.

The alternatives address different parts of the Field Service model. A normal reschedule changes a selected appointment but does not provide the same schedule-wide rearrangement around the incoming high-priority work; custom Apex is unnecessary.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Scheduling and Optimization — Reshuffle; appointment priority; in-day schedule adjustment.

For this scenario, Salesforce Field Service should use Skills, Skill Requirements, and Service Resource Skills. Skills define capabilities, Skill Requirements state what the work needs, and Service Resource Skills record what each technician possesses and at what proficiency level. Together they provide the complete data model required for skill-based scheduling.

For resource design, the consultant should model the real operational constraint at the correct layer: skills for expertise, capacity for outsourced workload, crew membership for coordinated teams, Operating Hours and absences for availability, and permission sets for user capabilities. Mixing these concepts leads to inaccurate scheduling behavior and unnecessary customization.

The alternatives address different parts of the Field Service model. Work Types can standardize the requirements but do not replace the underlying Skill and Service Resource Skill records. Routing rules and Work Order statuses do not represent expertise.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Resources — Skills; Skill Requirements; Service Resource Skills.

Street Level Routing and Default Travel Speed is the appropriate Field Service design. Street Level Routing uses road-network information to produce more realistic point-to-point travel estimates. Default Travel Speed is also important for aerial routing and acts as the fallback when a resource-specific speed is not configured.

Salesforce Field Service treats the Service Appointment as the primary unit of scheduling. Scheduling Policies combine Work Rules, which determine whether a resource or time slot is valid, with Service Objectives, which score valid alternatives against business priorities. The selected configuration therefore has to operate at the scheduling layer rather than merely changing descriptive fields on the parent Work Order.

The alternatives address different parts of the Field Service model. Actual Travel Time records what happened after travel, while Minimize Travel is an objective and does not correct an unrealistic underlying estimate.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Scheduling and Optimization — Street Level Routing; Default Travel Speed; travel-time accuracy.

Earliest Start Permitted and Due Date is the appropriate Field Service design. These fields define the internal scheduling window that represents when the appointment may begin and the latest time by which it should be completed. They are the Service Appointment fields most directly aligned with SLA constraints.

Operationally, the goal is to preserve schedule integrity while minimizing manual intervention. Field Service should be allowed to use the standard scheduling engine wherever possible so that resource availability, travel, appointment constraints, priorities, and territory context remain consistent across manual and automated scheduling actions.

The alternatives address different parts of the Field Service model. Scheduled Start/End are scheduling outcomes, Actual Start/End record execution, and Arrival Windows are customer-facing arrival expectations rather than the core SLA boundaries.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Scheduling and Optimization — Service Appointment constraints; Earliest Start Permitted; Due Date.

The requirement is best implemented with consistent Quantity Unit of Measure values. Bulk materials such as sealant should be tracked in a meaningful unit such as liters, with the Product and its required/consumed inventory records using consistent unit semantics. This preserves accurate quantity depletion and costing when technicians use partial quantities.

Field Service inventory distinguishes the product catalog from stock at a location and from inventory movement or consumption. Products define what the item is, Product Items represent how much of that Product is at a specific Location, Products Required describe planned needs, and Products Consumed record what was actually used during execution.

The alternatives address different parts of the Field Service model. Creating a new Product for every container size or forcing whole-container consumption would distort inventory, while using inconsistent units risks incorrect stock calculations.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Inventory — Quantity Unit of Measure; Products Required; Products Consumed.

Appointment List and Color Palettes is the appropriate Field Service design. The Appointment List exposes rule-violating appointments for operational review, while Color Palettes visually distinguish appointments on the Gantt based on selected criteria. Together they let dispatchers identify exceptions quickly without opening each record.

Operationally, the goal is to preserve schedule integrity while minimizing manual intervention. Field Service should be allowed to use the standard scheduling engine wherever possible so that resource availability, travel, appointment constraints, priorities, and territory context remain consistent across manual and automated scheduling actions.

The alternatives address different parts of the Field Service model. The Gantt and Gantt Map are broad presentation surfaces; the question asks for the features used specifically to visualize and distinguish rule violations.

This approach keeps the implementation aligned with the standard Field Service data model and avoids unnecessary customization. Study Guide reference: Managing Scheduling and Optimization — Dispatcher Console; Appointment List; Color Palettes; rule violations.