Field Service Consultant Interview Questions

The FSL data model centers on: (1) Work Order — the top-level service request, linked to an Account, Contact, and optionally an Asset or Case. (2) Work Order Line Item — individual tasks or steps within a Work Order. (3) Service Appointment — a scheduled visit linked to a Work Order or Line Item with start/end times. (4) Assigned Resource — junction object linking a Service Appointment to a Service Resource. (5) Service Resource — the technician, crew, or equipment performing work. (6) Service Territory — a geographic area. (7) Service Territory Member — links a resource to a territory with a role (primary or relocation). (8) Operating Hours — define business hours for territories and resources. (9) Time Sheet / Time Sheet Entry — track actual labor hours against service appointments.

FSL provides four optimization types: (1) Global Optimization — reschedules all unscheduled and scheduled appointments across the full horizon; used for initial schedule builds or major replanning. (2) Overnight Optimization — runs automatically overnight to build the optimal schedule for the next day before technicians start work. (3) In-Day Optimization — re-optimizes the current day's remaining appointments in real time as cancellations, new requests, or delays occur. (4) Resource Schedule Optimization — optimizes the schedule for a single named resource, useful when a specific technician's day needs to be replanned without affecting others. All optimization types use the configured Scheduling Policy (service objectives and work rules) to generate the optimal schedule.

A Scheduling Policy is the set of rules and objectives that govern how the FSL optimizer assigns and sequences appointments. It contains two components: (1) Service Objectives — business goals the optimizer tries to achieve, each with a weight. Common objectives include Minimize Travel (reduce total travel distance/time), Maximize Attendance (favor resources with relevant skills), and Customer First (minimize arrival window deviation). Higher-weighted objectives take precedence. (2) Work Rules — hard constraints the schedule must satisfy, such as Matching Skills (resource must have required skills), Availability (resource must be within operating hours), Required Resource (a specific resource must be assigned), and Excluded Resource. Work rules are always respected; service objectives are balanced goals.

The Dispatcher Console is the FSL control center for service managers and dispatchers. Key features: (1) Gantt Chart — a time-based visual schedule showing all resources (rows) and their appointments (blocks) across the day or week; dispatchers can drag-and-drop appointments to reassign or reschedule. (2) Map View — displays resource locations and appointment addresses geographically. (3) Unscheduled Appointments List — shows open appointments not yet on the Gantt. (4) Filter Panel — filters resources by territory, skill, availability. (5) Multi-Resource Scheduling — assign multiple resources to a single appointment (crew work). (6) Callout Map — shows customer addresses to assist in geographic dispatching decisions. Dispatchers can manually schedule, cancel, or optimize schedules from this interface.

Skill-based routing matches service appointments to resources based on the skills required for the job. Configuration: (1) Define Skill Types (e.g., "HVAC Certification," "Electrical License") in FSL Settings. (2) Assign Skills to Service Resources with a proficiency level (numeric scale). (3) Define Required Skills on Work Types or directly on Service Appointments — specifying skill name and minimum proficiency level. (4) The Scheduling Policy must include the "Matching Skills" work rule set to Required. When scheduling, the optimizer only assigns resources whose skill set meets all requirements. If a resource lacks a required skill, the assignment is blocked unless the work rule is set to Preferred (soft constraint) rather than Required.

Work Types are templates that standardize the definition of common service tasks. They define: (1) Estimated Duration — how long the task is expected to take (used by the optimizer for scheduling). (2) Scheduling Policy — the default policy applied when scheduling appointments of this type. (3) Required Skills — skills and proficiency levels needed to perform the work. (4) Time Slots — the operating hours during which this work type can be performed. (5) Timeframe Start/End — if Einstein Work Duration Prediction is enabled, predictions refine estimated duration. Work Types are associated with Work Orders and Service Appointments, and can also be linked to Maintenance Plans for auto-generated recurring work orders.

FSL parts management uses these objects: (1) Product Items — inventory records representing physical stock at a Service Location (e.g., van stock, warehouse). (2) Product Consumed — tracks parts used on a Work Order or Line Item, reducing inventory on the Product Item. (3) Product Request and Product Request Line Items — a request for parts to be transferred to a location or resource. (4) Product Transfer — records the movement of stock between locations. (5) Return Order and Return Order Line Items — track parts returned from a job site to a warehouse. This end-to-end chain supports full inventory visibility from warehouse to technician van, enabling accurate parts usage reporting and replenishment planning.

Maintenance Plans automate the creation of recurring Work Orders for preventive maintenance on assets. Configuration: (1) Create a Maintenance Plan linked to one or more Assets or Accounts. (2) Associate a Work Type to define the type of work. (3) Set the frequency (daily, weekly, monthly, yearly) and the maintenance window (suggested date range). (4) Define the generation method: auto-generate Work Orders on a schedule or generate on completion of the previous work order. (5) When the auto-generation trigger fires (via a scheduled job), Salesforce creates Work Order records with the associated Line Items and links them back to the Maintenance Plan and Asset. This ensures regular service intervals are never missed without manual intervention.

Service Contracts are agreements between a company and its customers defining the terms of service — response times, coverage hours, and covered products. In FSL: (1) Entitlements on the Service Contract define specific SLA commitments (e.g., 4-hour on-site response). (2) Covered Products (Contract Line Items) specify which Assets or products are included under the contract. (3) When a Work Order is created for an asset, Salesforce can auto-populate the Entitlement based on the active Service Contract, triggering milestone timers. (4) Service contracts also drive billing cycles when integrated with Salesforce Billing, ensuring service delivery is tied to contractual obligations and invoiced accordingly.

Resource Absences mark a Service Resource as unavailable for a defined period, preventing the optimizer from scheduling appointments during that time. Absence types: (1) Full Day — the resource is unavailable for one or more complete days (e.g., vacation, training). (2) Time Range — the resource is unavailable during a specific time window within a day (e.g., doctor's appointment from 2–4 PM). Absences are visible on the Dispatcher Console Gantt as a blocked period. If a resource already has appointments during an absence period, the dispatcher receives a conflict warning. The optimizer will not assign new appointments that overlap with a resource absence, ensuring scheduling accuracy.

Crew management allows multiple technicians to be assigned to a single Service Appointment as a team. Key concepts: (1) Service Crew — a group of Service Resources with a designated Crew Leader. The crew is created as its own Service Resource of type Crew. (2) Crew Members — individual technicians assigned to the crew, each also appearing as independent Service Resources. (3) When a Service Appointment is assigned to a crew, all crew members are simultaneously dispatched and the appointment appears on each member's mobile schedule. (4) Simultaneous Dispatching — Dispatchers can assign crew members individually or dispatch the entire crew at once. Skills are validated at the crew level (combined skills of all members satisfy requirements).

Service Reports are auto-generated PDF summaries of work performed during a service visit. They are created from Work Orders and Work Order Line Items. Key features: (1) Report Templates — configurable templates define which fields, related data (parts consumed, labor time), and branding appear on the PDF. (2) Auto-Generation — a Service Report can be automatically generated when a Work Order status changes to a completion status (via Flow or Process Builder). (3) Signature Capture — the Field Service mobile app prompts the customer to sign the report directly on a mobile device; the signature is embedded in the generated PDF. (4) Reports are stored as Salesforce Files attached to the Work Order and can be emailed directly to the customer.

The Field Service Mobile app supports offline capability for technicians in areas with poor or no connectivity. Offline-supported actions include: viewing and updating Work Orders and Service Appointments, accessing and updating Work Order Line Items, viewing installed Products/Assets, logging Products Consumed, capturing signatures, taking and attaching photos, viewing Knowledge Articles (if pre-synced), and completing Time Sheets. Actions that require online access include running optimization, querying non-cached records, and Salesforce Flow actions. Data entered offline is stored in a local database and synced automatically when connectivity is restored, with conflict detection.

Customer appointment notifications keep customers informed about their upcoming service visits. Methods: (1) Email Notifications — triggered automatically via Flow or Process Builder when a Service Appointment is scheduled, rescheduled, or the technician is en route. (2) SMS Notifications — sent via Salesforce Flow using an SMS action (requires an integrated messaging provider). (3) Automated Notification Flows — a Record-Triggered Flow fires on Service Appointment status changes (e.g., "Dispatched," "En Route," "Completed") to send the appropriate message. Notifications can include appointment window details, technician name, and a tracking link. Customer consent records should be verified before sending SMS notifications.

Assets in FSL represent installed products at customer locations. Key capabilities: (1) Assets are linked to Accounts (the customer) and can reference the parent Product record. (2) Asset Relationships allow modeling of hierarchical or peer relationships between assets (e.g., a compressor as a child of a HVAC unit). (3) Work Orders can be linked directly to an Asset to track service history on specific equipment. (4) Maintenance Plans can be generated from Assets for scheduled preventive maintenance. (5) The Asset 360 view in FSL provides a complete service history timeline for each asset. (6) Asset health, installation date, and warranty information drive decisions about repair vs. replace recommendations.

Einstein Work Duration Prediction uses machine learning to predict how long a service appointment will take, improving scheduling accuracy over the static estimated duration on Work Types. How it works: (1) Training Data Requirements — the model requires a minimum number of historical completed Work Orders (typically 1,000+) with actual vs. estimated duration data. (2) Einstein analyzes patterns including work type, asset type, location, and resource to generate predictions. (3) Enabling — activated via Einstein Setup in FSL Settings; once enabled, predictions appear as a predicted duration field on Service Appointments and Work Types. (4) Prediction Accuracy improves over time as more completed work order data is fed back to the model. Schedulers can choose to use the predicted or estimated duration for optimization.

Appointment bundling groups multiple Service Appointments into a single technician visit, reducing travel overhead when multiple jobs are in close proximity. Configuration: (1) Create a Bundle Policy that defines bundling criteria — maximum bundle size (number of appointments), maximum total duration, same-day requirement, and geographic radius. (2) Enable Appointment Bundling in FSL Settings and assign the Bundle Policy to relevant Scheduling Policies. (3) When the optimizer runs, it evaluates appointments that meet the bundle criteria and groups them into a Bundle Work Order. (4) Same-Day Bundling is the most common pattern — grouping nearby appointments that can all be serviced in a single technician day trip. Bundled appointments share a single Service Appointment parent record, and the technician visits them sequentially.

Resource productivity is measured using standard Salesforce reports on FSL objects: (1) Time Sheet Reports — summarize actual vs. scheduled hours per resource using Time Sheet Entry data. (2) Service Appointment Reports — track appointments per resource, completion rates, and schedule adherence. (3) Travel Time Reports — compare estimated vs. actual travel time using Service Appointment fields. (4) Products Consumed Reports — track parts usage per resource or work order type. These reports can be combined in dashboards with charts showing utilization rate (scheduled time / available time), on-time arrival percentage, and first-time fix rate. CRM Analytics (Tableau CRM) for FSL provides prebuilt analytics templates with deeper drill-down capability.

Service territories can be organized in a parent-child hierarchy to reflect real-world geographic or organizational structures (e.g., Region > District > City). The hierarchy is used for: (1) Dispatcher Console Filtering — dispatchers can view the Gantt for all resources within a parent territory and all its children. (2) Relocation Territories — a technician assigned as a member of a child territory can be designated as a "Relocation" member of the parent territory, allowing them to work in adjacent areas when needed. (3) Operating Hours Inheritance — child territories can inherit operating hours from the parent. (4) Optimization Scope — the optimizer can be scoped to a specific territory and all its children for focused regional optimization.

Salesforce Maps (formerly MapAnything) provides geospatial visualization and routing capabilities that enhance FSL: (1) Live Tracking — real-time technician location updates on the Dispatcher Console map, powered by Maps Live or the FSL mobile app GPS. (2) Route Optimization — turn-by-turn navigation for technicians with traffic-aware routing, integrated with the Field Service Mobile app. (3) Territory Planning — visual territory boundary creation and balancing using Maps Territory Planning. (4) Marker Layers — overlay customer locations, appointment addresses, and resource positions on a single map. (5) Drive-Time Analysis — calculate realistic travel times between appointment locations for scheduling. Maps data feeds into the FSL Scheduling Policy to improve travel-time estimates used by the optimizer.

Technician type Service Resources represent individual workers linked to a Salesforce user. They have their own capacity, skills, operating hours, and can be assigned independently to Service Appointments. Crew type Service Resources represent a team of technicians working together. A Crew has a designated Crew Leader and a set of Crew Members. When a Service Appointment is assigned to a Crew, all members are dispatched simultaneously. Crews appear on the Dispatcher Console Gantt as a single row, but each individual member's schedule is also updated. Crews are best for jobs requiring multiple technicians (e.g., heavy equipment installation) where coordinated dispatch is essential. Individual members can also still be assigned to solo appointments outside crew work.

Operating Hours define when a Service Territory or Service Resource is available for scheduling. Configuration: (1) Create an Operating Hours record with a name and time zone. (2) Add Time Slots for each day of the week, specifying start and end times. Multiple time slots can be added per day (e.g., a morning shift and an afternoon shift). (3) Assign the Operating Hours record to the Service Territory (default hours for the area) and/or directly to individual Service Resources (overrides territory hours for that resource). (4) Operating Hours integrate with Holiday records — Holidays linked to Operating Hours automatically block those days from scheduling without manual absence creation. The optimizer and manual scheduling both respect Operating Hours when assigning appointments.

A Product Request is a forward-looking record that a technician or dispatcher creates to request that specific parts be made available for an upcoming job. It contains Product Request Line Items specifying which products are needed, the quantity, and the destination location (e.g., technician's van). The warehouse can fulfill the request by initiating a Product Transfer. A Product Consumed record is a backward-looking record created after a job is complete, documenting which parts were actually used on a Work Order Line Item. It reduces inventory from the associated Product Item. In summary: Product Request = "I need these parts" (before the job); Product Consumed = "I used these parts" (after the job).

Field Service Lightning is a managed package installed on top of a Salesforce org (Sales Cloud or Service Cloud). It adds the FSL objects, the Dispatcher Console, and the scheduling engine. License types: (1) Field Service Dispatcher — for dispatchers using the Dispatcher Console; includes Gantt and optimization access. (2) Field Service Technician — for field workers using the mobile app; allows Work Order and mobile features. (3) Field Service Scheduling — for scheduling optimizer and resource management without console access. The FSL managed package version must be updated separately from Salesforce core releases. Core CRM functionality (Accounts, Contacts, Cases) is available without FSL licenses; only FSL-specific objects and features require FSL licenses.

A Return Order records the process of returning parts or products from a field location (e.g., a technician's van or a customer site) back to a warehouse or service depot. It is used in scenarios such as: (1) A technician removes a defective part from a customer's asset and needs to return it to the depot for inspection or warranty processing. (2) Excess or unused parts need to be returned to central inventory. Return Orders contain Return Order Line Items specifying each product, quantity, and reason for return. The system can automatically adjust Product Item quantities at the source location when the return is processed. Return Orders integrate with Salesforce Billing for credit processing if the return is associated with a customer refund scenario.