FSL = Service Cloud extension for field operations | Three user types: Dispatcher (office), Mobile Worker (field), Admin | Key objects: Work Order, Service Appointment, Service Resource, Service Territory | FSL managed package: installed on top of Salesforce | Mobile App: FSL offline-capable mobile app for field technicians | Industries: utilities, telecom, healthcare equipment, manufacturing, facilities management

Work Order: the job to be performed — linked to Account, Contact, Case, Asset | Work Order Line Item: individual tasks within a Work Order | Service Appointment: scheduled instance — links Work Order to Service Resource with date/time | Service Resource: a technician or crew (User or Account) | Service Territory: geographic region | Operating Hours: when work can be scheduled | Skill: technician capability required for job

Work Order fields: Subject, Status (New, In Progress, Completed, Cancelled), Priority, Account, Contact, Asset, Location, Duration, Service Territory | Work Order Line Items: individual tasks (Replace Filter, Test Pressure, Document Results) | Status transitions: New → Dispatched → In Progress → Completed | Parent-child: Work Order can have multiple Work Order Line Items | Asset: the specific equipment being serviced

SA fields: ParentRecordId (Work Order/WO Line Item), Status (None, Scheduled, Dispatched, Completed, Cannot Complete), SchedStartTime, SchedEndTime, EarliestStartTime, DueDate, Duration, ServiceTerritoryId | Multiple SAs: a Work Order can have multiple Service Appointments | Status flow: None → Scheduled → Dispatched → In Progress → Completed | Assigned resource: linked via ServiceAppointmentAssignedResource junction object

Service Resource types: Technician (linked to User), Crew Member (linked to User), Crew (group of technicians), Equipment (non-human resource) | Key fields: Name, ResourceType (Technician/Crew/Equipment), RelatedRecord (User or Account), IsActive, Capacity | Service Territory Member: links Service Resource to Service Territory | Skills: Service Resource Skill records link skills to technicians with expiry dates | Availability: defined via Operating Hours or Resource Absences

Service Territory: geographic area | Hierarchy: Parent → Child territories (e.g., India → Maharashtra → Mumbai) | Service Territory Member: links Service Resource to Service Territory | Member Type: Primary (home territory) or Secondary (can also serve) | Polygons: FSL can use geographic polygon boundaries for territory | Operating Hours: Service Territory has its own operating hours | Impact: scheduling only assigns technicians to jobs in their territory

Operating Hours object: linked to Service Territory or Service Resource | Time Slots: child records defining Day of Week + Start Time + End Time | Multiple time slots: Mon-Fri 8AM-6PM, Sat 9AM-1PM | Override: Service Resource Operating Hours override Service Territory Operating Hours | Holiday: Resource Absences override Operating Hours for individual days | Impact: no Service Appointment will be scheduled outside Operating Hours unless forced

Skill object: Name, Description | Service Resource Skill: links Skill to Service Resource — SkillLevel (0-100%), StartDate, EndDate (expiry) | Required Skill: links Skill to Work Type or Work Order Line Item | Skill matching: scheduling engine only assigns technicians who have all Required Skills for the job | Skill expiry: expired skills not used for matching | Skill level: some optimizations consider skill level for best-fit matching

Work Type fields: Name, EstimatedDuration, OperatingHours, RequiredSkills, BlockTimeBeforeAppointment, BlockTimeAfterAppointment | Templates: Work Type Line Items define standard tasks | Inheritance: Work Order created from Work Type inherits duration, skills, line items | Use case: Preventive Maintenance (2 hours, standard tasks), Emergency Repair (1 hour minimum, Electrical skill required), Annual Inspection (4 hours, Inspector skill) | Standardization: ensures consistent job setup across all technicians

Maintenance Plan fields: MaintenancePlanTitle, Frequency, FrequencyType (Days/Weeks/Months/Years), GenerationTimeframe (how many WOs to create ahead), WorkType, MaintenancePlanDuration | Maintenance Work Rules: child records defining specific schedules | Trigger: when a Maintenance Work Order is completed, FSL automatically creates the next one | Asset: linked to specific equipment on Maintenance Plan | Generation: Apex scheduler generates Work Orders based on plan

Dispatcher Console features: Gantt view (appointments on timeline per technician), Map view (appointments on geographic map), List view (appointment queue) | Actions: schedule (assign appointment to technician), dispatch (send to technician's mobile app), unschedule, cancel | Filters: by Service Territory, date range, appointment status, skills | Real-time: updates when technicians complete jobs or new appointments come in | Candidate technicians: shows eligible technicians for unscheduled appointments

Scheduling Policy components: Work Rules (hard constraints — must be respected) and Service Objectives (optimization goals — prioritized) | Work Rules: Match Skills (required), Match Territory, Working Locations, Required Resources | Service Objectives: Minimize Travel, Maximize Skills Match, Preferred Resources, Customer First | Priority: Work Rules are mandatory, Service Objectives are weighted goals | Multiple policies: Emergency Policy (speed-focused), Standard Policy (balanced), Maintenance Policy (travel-optimized)

Status flow: None → Scheduled → Dispatched → In Progress → Completed (or Cannot Complete) | Scheduled: appointment assigned, technician not notified | Dispatched: appointment sent to FSL Mobile App — technician notified | In Progress: technician has started the job (checked in) | Completed: technician marked job done | Cannot Complete: technician could not finish (parts unavailable, access denied) | Auto-dispatch: can be configured to auto-dispatch on scheduling

Resource Absence fields: ServiceResourceId, Start, End, Type (Holiday, Break, Medical, Training, Personal) | Effect: scheduling engine skips the technician for any appointment overlapping the absence | Manual: dispatchers can still force-assign during absence (override) | Integration: HR system integration can auto-create Resource Absences from approved leave requests | Planning: show future absences on Dispatcher Console for capacity planning

FSL Mobile: offline-capable — technicians work without internet, syncs when connected | Features: appointment list, Work Order details, navigation (Google Maps/Waze integration), asset history, Knowledge articles, signature capture, photo upload, barcode scanner | Status updates: technician marks En Route, On Site, In Progress, Completed from mobile | Parts: request parts, record parts used | Custom actions: configurable quick actions on mobile

Crew object: Name, ActiveStartDate, ActiveEndDate, Capacity | Crew Member: links Service Resource to Crew with role (Lead, Member) | Crew scheduling: when Crew is assigned to SA, all crew members' calendars are blocked | Crew skills: crew inherits the combined skills of all members | Use cases: large equipment installation (3-person crew), complex infrastructure work, safety-mandated 2-person jobs | Dynamic crews: membership can change per job

Asset object (standard Salesforce object extended for FSL) | Key fields: Name, SerialNumber, AccountId, LocationId, Status (Installed, Registered, Obsolete), PurchaseDate, UsageEndDate, InstallDate | Asset relationships: Account (owner), Contact (user), Location (where installed), Product2 (what it is) | Service history: all Work Orders linked to Asset show complete service history | Warranty: Asset warranty fields track coverage | FSL: work orders for specific assets enable asset-centric service

Location object: Name, LocationType (Site, Van, Warehouse, Branch), Latitude, Longitude, Street, City, State | Location hierarchy: parent-child locations (Building → Floor → Room) | Service Resource location: technician home base | Asset location: where equipment is installed | Work Order location: where job will be performed | Geocoding: latitude/longitude enables map view and travel time calculations | Parts: inventory tracked at Location (van stock, warehouse)

FSL package namespace: FSL__ prefix | Installation: AppExchange → Field Service managed package | Requires: Service Cloud license + FSL license per user | Optimizer: external Heroku-based optimization engine — communicates via REST API | Objects added: Service Appointment, Service Resource, Service Territory, Operating Hours, Skill, Work Type, Maintenance Plan and more | Upgrades: managed package upgrades 2-3 times per year — test in sandbox first | Permission Sets: FSL provides standard permission sets (Dispatcher, Mobile Worker, Admin)

FSL Permission Sets: Field Service Admin (configure FSL, all access), Field Service Dispatcher (Dispatcher Console, schedule and dispatch SAs), Field Service Mobile (FSL Mobile App access, update job status), Field Service Scheduling (run optimization algorithms) | Assignment: each user needs appropriate permission set + FSL license | Multiple: a user can have multiple permission sets | Custom: create custom permission sets based on FSL standard sets | Best practice: never modify standard FSL permission sets — clone and customize

Scheduling engine types: Automated (no human involvement), Semi-automated (suggests candidates, dispatcher confirms), Manual (dispatcher assigns manually) | Actions: Schedule (assign one appointment), Global Optimization (reschedule all appointments in territory), In-Day Optimization (reoptimize remaining day appointments) | Triggers: button click, Apex call, or auto-schedule on SA creation | Response: returns scheduled appointments with assigned resource and time

Global Optimization: reschedules all SAs in territory for the optimization horizon | Trigger: manual button in Dispatcher Console or scheduled Apex | Time horizon: typically next 1-7 days | Output: completely optimized schedule — technicians' days reorganized for minimum travel | Impact: can move already-scheduled appointments | Dispatched SAs: by default, already-dispatched SAs are not moved (configurable) | Duration: seconds to minutes depending on volume

In-Day Optimization: reschedules remaining (not yet started) SAs for current day | Trigger: manual button, scheduled Apex (e.g., every 2 hours), or event-based (emergency SA created) | Scope: only future SAs for today — does not touch completed or in-progress | Use case: technician calls in sick (resource absence created) → IDO reassigns their remaining jobs to other technicians | Speed: faster than Global Optimization (smaller scope)

Automatic: scheduling engine assigns SA directly — no dispatcher action required | Semi-automatic: engine returns ranked candidates, dispatcher confirms | Manual: dispatcher assigns SA from Dispatcher Console without engine suggestions | Triggers: configured per Work Type or Service Territory | Use cases: Automatic for standard preventive maintenance (predictable, low risk), Semi-automatic for emergency repairs (dispatcher verifies parts availability, customer preferences), Manual for VIP customers (account team involvement)

Work Rules (hard constraints — cannot be violated): Match Skill (technician must have required skills), Match Territory (technician must be in same territory), Working Locations (technician must be at valid location), Required Resources (specific technician must be assigned), Excluded Resources (specific technician must NOT be assigned), Service Appointment Crew Size (crew size requirements) | Contrast to Service Objectives: objectives are optimization goals, work rules are mandatory

Service Objectives (weighted optimization goals): Minimize Travel (reduce drive time between jobs), Maximize Skill Match (prefer technicians with higher skill levels), Preferred Resources (prefer customer-preferred technicians), Customer First (respect customer time window preferences), Soft Boundaries (prefer primary territory technicians over secondary) | Weight: each objective has a weight (0-100) — higher weight = more important | Balance: sum of weights = 100 | Multiple objectives: engine balances all simultaneously

Drip Feed: auto-dispatches SA X minutes/hours before SchedStartTime | Configuration: set dispatch lead time (e.g., 2 hours before appointment) | Benefit: only dispatch when job is confirmed — reduces morning re-dispatch when overnight changes occur | Contrast to bulk dispatch: dispatching all jobs at once means many re-dispatches if anything changes | Implementation: scheduled Apex or Process Builder checks appointments and dispatches at configured lead time | Mobile experience: technician sees their next job appear on mobile as day progresses

Schedule Over Horizon: configured in Scheduling Policy | Purpose: prevents scheduling too far in advance (schedules become irrelevant as circumstances change) | Typical values: 7 days (reactive field service), 30 days (planned maintenance), 90 days (long-lead installation projects) | Impact: SA with EarliestStartTime beyond horizon stays Unscheduled until it enters the horizon | Maintenance Plans: often use longer horizons (30-60 days) | Emergency: horizon ignored for Critical Priority SAs — scheduled immediately

Gantt features: each row = one Service Resource, each block = one Service Appointment | Color coding: by SA status (Scheduled, Dispatched, In Progress, Completed), priority, or Work Type | Drag and drop: move appointments between technicians or reschedule by dragging | Zoom: hour-by-hour or day-by-day view | Travel time: travel time between appointments shown as gray blocks | Violations: SAs violating SLA highlighted in red | Filters: by Service Territory, date range, technician, status

Map View features: technician real-time locations (if location tracking enabled), appointment pins by status, territory polygon overlays, travel routes | Candidate matching: click an unscheduled appointment → map shows eligible technicians with distance and travel time | Real-time: technician GPS location updates via FSL Mobile | Territory visualization: service territory boundaries shown on map | Candidate list: sorted by proximity, skill match, availability | Use case: emergency dispatch — find nearest available qualified technician

Emergency scheduling: Priority field on SA set to Critical or Emergency | Automatic: scheduling engine immediately finds best available technician — ignores Schedule Over Horizon | Override: can be configured to bump lower-priority SAs to accommodate emergency | Immediate dispatch: emergency SAs auto-dispatched via Drip Feed or immediate dispatch | IDO: In-Day Optimization triggered after emergency insertion to rebalance remaining schedule | SLA: emergency SAs typically have tightest SLA windows (2-4 hours)

Bundling: group multiple SAs at same location into one visit | Bundle Policy: defines when bundling applies (same location, within X km, same time window) | Bundle Lead: one SA designated as the lead of the bundle | Scheduling: bundle scheduled as one unit — all SAs in bundle assigned same technician and time slot | Use cases: multi-tenant buildings (service multiple units in one visit), adjacent customer sites, same-day follow-ups | Benefit: significant travel reduction for high-density service areas

Time window constraints: EarliestStartTime and DueDate on SA define the window | Customer time windows: ServiceAppointmentRequestedDate and RequestedStartTime fields | SA dependencies: SAs can be linked so SA2 is blocked until SA1 is completed | Required resources: specific technician must be assigned | Location constraints: job must be performed on-site | Impact on optimization: constraints reduce feasible assignment options — too many constraints can make scheduling impossible | Best practice: minimize hard constraints, use Service Objectives for soft preferences

DueDate: the SLA deadline on Service Appointment | Visual warning: SAs approaching DueDate highlighted yellow/red in Dispatcher Console | SLA breach: SA past DueDate shown in red | Automated alerts: Flow or Apex sends alert to dispatcher when SA is X hours from DueDate and still unscheduled | Reporting: CRMA dashboards for SLA compliance by territory, technician, priority | KPIs: First Response Time (SA creation to dispatch), Mean Time to Resolution (SA creation to completion)

Work Order: WHAT — job description, customer, asset, duration, skills required | Service Appointment: WHEN and WHO — scheduled time, assigned technician, status | Relationship: one Work Order can have multiple Service Appointments | Multiple SAs: initial diagnosis SA + repair SA + follow-up SA all linked to one Work Order | Work Order status vs SA status: Work Order tracks overall job status, SA tracks individual visit status | Parent: Work Order Line Items can also be the parent of SAs for granular scheduling

Enhanced Scheduling: newer FSL scheduling configuration | Stages: separate configuration for Candidate Finding (who is eligible), Scheduling (when to assign), Optimization (how to optimize) | Benefits: more granular control, better performance for large territories | Older Scheduling Policy: still supported but Enhanced Scheduling is the recommended direction | Work Rules and Service Objectives: still apply but configured differently in recipes | Migration: existing Scheduling Policies can coexist with Scheduling Recipes

Resource Optimization: premium FSL add-on | Capabilities beyond standard: handles 100,000+ SAs/day, complex multi-objective optimization, predictive scheduling based on historical patterns | Machine learning: learns from past scheduling decisions to improve future assignments | Extended optimization horizon: schedule weeks ahead with high confidence | Real-time adaptation: instantly reoptimizes when disruptions occur | Requires: separate license on top of FSL | Industries: large utilities, telecom, logistics with massive field operations

Absence Types: Holiday, Break, Medical, Training, Personal, Other | RecordType on Resource Absence: maps to absence type | Business rules per type: Medical absence → auto-trigger IDO for same-day job reassignment; Training absence → flag for manager to reassign scheduled jobs; Break → do not schedule during break but no job reassignment | Reporting: absence patterns by type help identify capacity issues | Integration: HR system pushes approved leaves as Resource Absences

Multi-Resource SA: one SA with multiple ServiceAppointmentAssignedResource records | vs Crew: Crew is a pre-defined group, Multi-Resource is ad-hoc per SA | Required Crew Size: configure minimum technicians needed | Lead resource: one resource designated as lead | Skills: combined skills of all assigned resources must meet job requirements | Scheduling: engine finds combination of available resources that satisfy all requirements | Dispatch: all assigned resources dispatched simultaneously

Status values: None, Scheduled, Dispatched, En Route, On Site, In Progress, Completed, Cannot Complete, Canceled | En Route: technician started traveling to job | On Site: technician arrived at customer location | Cannot Complete: technician could not finish — reason captured (parts unavailable, access denied, safety concern) | Automations: each status transition can trigger Flow (e.g., Completed → update Asset last service date, Cannot Complete → create follow-up SA) | Customer notification: status changes can trigger customer SMS/email

Configuration: Service Territory → New → set ParentTerritoryId for child | Hierarchy levels: Country → State → City → District → Zone (configure as needed) | Territory member assignment: technicians assigned to the most specific territory level | Scheduling: uses the technician's Primary territory for scheduling, Secondary for overflow | Territory boundaries: define geographic polygons in FSL settings for map visualization | Best practice: match territory hierarchy to operational management hierarchy

ServiceTerritoryMember fields: ServiceResourceId, ServiceTerritoryId, TerritoryType (Primary or Secondary), EffectiveStartDate, EffectiveEndDate | Primary: technician home territory — first assignment preference | Secondary: overflow territory — used when Primary territory has insufficient capacity | Multiple territories: one technician can have one Primary + multiple Secondary | Operating Hours: territory member can have specific operating hours overriding territory operating hours | Effectiveness dates: model seasonal territory changes

Skill management: Service Resource → Skills related list → New Service Resource Skill | Fields: SkillId (lookup to Skill), ServiceResourceId, SkillLevel (0-100), StartDate, EndDate | Skill expiry: EndDate defines when certification expires — engine ignores expired skills | Bulk update: Data Loader for mass skill updates after training batches | Automation: Flow creates new Service Resource Skill record when training completion is logged | Reporting: skills expiry report — shows technicians with skills expiring in next 30/60/90 days

Capacity: set on Service Resource (CapacityInPercentage or hours) | Use cases: service vehicles (capacity = number of jobs), technicians with specialized equipment shared among team | Capacity reduction: Resource Absence reduces available capacity | Booking: each SA consumes a percentage of daily capacity | Overflow: when capacity reached, engine moves to next available resource | Combined with territories: capacity-aware territory management | Reporting: capacity utilization dashboard

Technician: human worker, linked to User, has skills, uses FSL Mobile App, has Operating Hours | Crew: group of Technicians, has Lead Technician, members can change, scheduled as a unit | Equipment: non-human (diagnostic tool, crane, specialized vehicle), no User link, no mobile app, capacity-based, must be co-assigned with technician SA | Configuration: ResourceType field on Service Resource | Scheduling: equipment and technician SAs coordinated for same time/location

Preferred Resource: ServiceAppointment field or configured on Account | Service Objective: Preferred Resources objective gives weight to preferred technician assignment | Exclusion: Excluded Resources prevents specific technicians from being assigned | AccountContactRelation: preferred technician linked to customer for automatic SA population | Override: preferred technician not always available — engine falls back to next best | Use case: VIP customers, recurring maintenance same technician (relationship building)

Crew object: ServiceResource with ResourceType = Crew | Crew Member: links Service Resources to Crew with roles (Lead, Member) | Lead: the responsible technician — receives primary dispatch notification | Members: receive dispatch notifications | Crew size: the scheduling engine can require minimum crew size for certain jobs | Dynamic crews: crew membership tracked with StartDate/EndDate on Crew Member | Skills: crew inherits skills of all active members | Dispatch: all crew members dispatched simultaneously

Service Territory Operating Hours: general territory business hours (Mon-Fri 8AM-6PM) | Service Resource Operating Hours: individual technician schedule (Mon-Fri 7AM-4PM for early shift) | Override: Service Resource Operating Hours OVERRIDE Service Territory Operating Hours | No Resource Operating Hours: technician defaults to Service Territory Operating Hours | Multiple time slots: both can have multiple time slots (early shift, late shift) | Impact: scheduling engine uses the more specific (Resource) hours when both exist

Location tracking: enabled in FSL Mobile settings on technician's phone | ServiceResource.Location: updated via FSL Mobile as technician moves | Dispatcher Console Map View: real-time technician pins on map | Location history: last known location stored | Privacy: location tracking policies must comply with local labor laws | Use case: dispatcher sees nearest technician to emergency, real-time ETA calculation | Geofencing: auto-update SA status when technician enters/exits customer site geofence

Assignment Status: None, Accepted, Declined | Set by: field technician on FSL Mobile App (Accept or Decline button) | Dispatcher visibility: Dispatcher Console shows Assignment Status alongside SA Status | Declined: technician declines → dispatcher notified → manual reassignment needed | Auto-accept: can configure to auto-accept on Dispatch (no technician confirmation required) | Use case: critical for jobs where technician confirmation is important before customer notification | Not to confuse with SA Status: they are separate fields

Secondary Territory Member: TerritoryType = Secondary on ServiceTerritoryMember | Scheduling preference: Primary territory members preferred over Secondary | Use when: Primary territory fully booked or Primary technicians lack required skill | Multiple secondary: one technician can be Secondary in multiple territories | Travel: secondary assignments involve more travel — considered in travel optimization | Boundary: Secondary membership typically in adjacent territories | Soft boundary: Scheduling Policy Service Objective can weight Primary vs Secondary preference

Resource Absence impact: technician invisible to scheduling engine during absence period | Already-scheduled SAs: engine does NOT automatically reassign — manual action or triggered automation (IDO) required | Dispatcher Console: absent technicians shown in gray on Gantt | Proactive management: review upcoming absences weekly and pre-reassign if needed | Automated reassignment: configure IDO trigger on Resource Absence creation to reassign same-day jobs | Capacity planning: aggregate absence data forecasts capacity gaps for hiring decisions

Service Report template: Visualforce or Lightning page template | Auto-generation: trigger on Work Order status = Completed | Content: Work Order details, Work Order Line Items completed, parts used, technician notes, before/after photos, customer signature | Storage: ContentDocument linked to Work Order | Delivery: auto-emailed to customer on completion | Custom templates: different templates per Work Type (PM report vs emergency repair report) | Mobile: technician generates service report from FSL Mobile before leaving site

Entitlement: Service Cloud object defining contracted service level | Fields: SlaType (response time), StartDate, EndDate, RemainingAmount (service calls left) | Connection to FSL: Case Entitlement → Work Order → Service Appointment Priority and DueDate automatically set | SLA: if customer has 4-hour SLA entitlement → SA DueDate = Case CreatedDate + 4 hours | Milestone: Entitlement Milestones track response and resolution time compliance | Contract Service Level: different customers get different SLA (Gold = 4 hours, Silver = 8 hours, Bronze = 24 hours)

Knowledge integration: Salesforce Knowledge articles accessible from FSL Mobile App | Contextual articles: Work Type and Asset linked to Knowledge articles | Technician workflow: open FSL Mobile → Service Appointment → Knowledge tab → relevant articles for this job type/asset | Search: technician can search Knowledge from mobile | Offline: articles can be pre-downloaded for offline access | Content types: troubleshooting guides, installation manuals, safety procedures, wiring diagrams | Benefit: reduces calls to supervisor, improves first-time fix rate

Parts Management objects: Product (part), ProductItem (inventory at location), ProductRequest (request parts), ProductTransfer (move parts between locations), ProductConsumed (parts used on Work Order) | van inventory: ProductItem records at Vehicle Location | Warehouse: ProductItem records at Warehouse Location | Low stock alert: Flows alert when van stock drops below threshold | Integration: ERP system for purchase orders and replenishment | Mobile: technicians record parts used directly from FSL Mobile

TimeSheet object: linked to Service Resource | TimeSheetEntry: individual time entries (date, start time, end time, Work Order, type) | Types: Regular, Overtime, Travel, Break | Approval: TimeSheet submitted by technician → reviewed by manager → approved | Mobile: technicians complete time entries from FSL Mobile App | Integration: approved TimeSheet data exported to payroll system | Analytics: actual vs estimated duration per Work Type, overtime trends by territory

Integration points: Case → Work Order (manual or automated via Flow/Apex), Entitlement → SA Priority and DueDate, Knowledge → FSL Mobile articles, Contact → Work Order customer, Account → Work Order account, Asset → Work Order asset | Feedback loop: Work Order completion → Case status update | Service Console: agents see Work Orders and SAs on Case record in Service Console | Omni-Channel: field service jobs can route through Omni-Channel to dispatchers

WOLI fields: WorkOrderId (parent), LineItemNumber, Subject, Description, Status, Duration, DurationType, StartDate, EndDate, RequiredSkills | Status: individual task status independent from Work Order | SA parent: WOLI can be the parent of a Service Appointment (for granular scheduling) | Progress: technician completes WOLIs individually on FSL Mobile | Completion: all WOLIs completed → Work Order automatically set to Completed (configurable) | Skills: WOLI can have different required skills than parent Work Order

Dispatcher permissions: view/edit SAs in their territory, Dispatcher Console access, schedule/dispatch/unschedule SAs, view all technician calendars, run optimization | Mobile Worker permissions: view own SAs, update own SA status, complete WOLIs, record parts used, capture signature, access Knowledge | Admin permissions: configure territories, skills, operating hours, scheduling policies, all object access | Data visibility: territory-based sharing — dispatcher sees only their territory's data | Custom PS: clone standard and customize as needed

Offline sync: data pre-downloaded to device when connected | Cached data: Service Appointments, Work Orders, WOLIs, Asset data, Knowledge articles, Customer details | Actions while offline: update SA status, complete WOLIs, record parts, capture signature, take photos | Sync: automatic sync on reconnection — merge server and local changes | Conflict resolution: server data wins for field-level conflicts | Pre-download: triggered when SA is dispatched — data downloaded before technician leaves | Limitations: cannot create new records offline (only update dispatched SAs)

FSL Mobile customization options: FSL Mobile Settings (which objects and fields show), Quick Actions (custom buttons on SA and Work Order), Mobile Flow (guided step-by-step workflows on mobile), Compact Layout (which fields show in appointment list), Branding (company logo and colors), Features on/off (barcode scanner, signature capture, geofencing, photo upload) | Custom objects: add custom object tabs to mobile app | Map integration: Google Maps or Waze for navigation

Geofencing: GPS-based location triggers | Enter customer site geofence → SA status automatically set to On Site | Exit customer site → SA completion prompt or automatic status update | Configuration: set geofence radius around customer Location record | Customer notification: auto-trigger when technician enters geofence — customer SMS/email with arrival notification | Privacy: technician GPS must be enabled | Reliability: geofence radius set large enough for GPS accuracy (typically 100-200 meters)

Gantt features: rows = Service Resources, columns = time (hourly or daily zoom) | Color coding: by status, priority, Work Type, or custom | Drag and drop: move SA to different technician row or different time slot | Travel time: gray blocks between appointments showing drive time | Violations: red highlighting for SLA breaches, skill mismatches | Filters: territory, date range, technician, status | Candidate list: click unscheduled SA → see eligible technicians ranked | Real-time: updates every 30 seconds as technicians update mobile status

List View features: filterable columns (status, priority, territory, DueDate, required skills), sortable, bulk-select for batch operations | Unscheduled queue: filter Status = None to see all unscheduled SAs | Priority filter: sort by priority to address critical SAs first | Skill filter: find SAs requiring specific skills | Bulk actions: select multiple SAs → schedule all with one click | Integration with Gantt: click SA in list → Gantt highlights eligible technicians | Customizable: configure which columns show in list view

Quick Actions: configured in FSL Mobile Settings | Types: Create Record (e.g., create ProductRequest), Flow (launch a guided flow), Apex (invoke custom logic) | Placement: on SA detail page, Work Order page, or Work Order Line Item | Visibility: show/hide based on conditions (e.g., only show Request Parts if status = On Site) | Common Quick Actions: Request Parts, Cannot Complete — Create Follow-Up, Escalate to Supervisor, Send Customer ETA, Take Before Photo

Cannot Complete: SA status on FSL Mobile | Reason codes: Parts Unavailable, Customer Not Present, Access Denied, Safety Concern, Equipment Issue | Actions on Cannot Complete: create follow-up SA (automatically or by technician), notify customer, update Work Order status, alert dispatcher | Follow-up SA: pre-populated with same Work Order, scheduled for next available slot | Analytics: Cannot Complete rate by reason — identifies systemic issues (high Parts Unavailable = supply chain problem)

Signature Capture: feature in FSL Mobile — must be enabled in Mobile Settings | Workflow: technician completes job → opens signature screen on mobile → customer signs with finger → signature saved as image | Storage: ContentDocument linked to Work Order or SA | Service Report: signature included in auto-generated service report PDF | Legal validity: electronic signatures accepted in most jurisdictions | Mandatory: configure as required step before technician can mark SA Completed | Language: signature confirmation text configurable

Barcode scanner: built into FSL Mobile App — uses device camera | Asset lookup: scan asset serial number barcode → FSL Mobile shows asset record, service history, and related Knowledge articles | Parts recording: scan part barcode → ProductConsumed record auto-populated with correct Product | QR codes: customer site QR code → opens Site Location record with instructions and contacts | Enable/disable: configured in FSL Mobile Settings | Use cases: utilities, manufacturing, facilities management — every asset has barcode

Candidate List: shown when dispatcher clicks an unscheduled SA | Ranking: sorted by fit score (composite of Service Objectives) | Information per candidate: name, territory, fit score, required skills match, available time slots, travel time from last job | Fit score: higher = better match for Scheduling Policy objectives | Actions: click candidate → view their Gantt for the day, confirm assignment | Filters: filter candidates by territory, skill, availability | Override: dispatcher can assign any eligible technician regardless of ranking

Key FSL KPIs: First Time Fix Rate (% jobs completed without return visit), MTTR (avg time from Case to Work Order Completion), SLA Compliance (% SAs completed within DueDate), Technician Utilization (% productive vs total available hours), Travel Time % (travel hours / total hours), Cannot Complete Rate, Customer Satisfaction (CSAT from post-service survey) | CRMA: pre-built Field Service Analytics app | Custom reports: Work Order by Work Type, SA by Territory, Skill utilization by technician

Appointment List: use for queue management, finding unscheduled SAs, bulk scheduling, filtering by priority/territory | Gantt: use for schedule visualization, identifying gaps, drag-drop rescheduling, travel time review, day-view planning | Map: use for emergency dispatch (find nearest technician), territory visualization, geographic clustering analysis, real-time technician tracking | Together: List → find unscheduled SA → switch to Map → find nearest eligible technician → assign → switch to Gantt → verify schedule fits logically

Common FSL Flows: Case → Work Order (on Case creation/status change), SA status → Customer SMS (on Dispatched, On Site, Completed statuses), Cannot Complete → Follow-up SA (creates next SA with reason), Resource Absence → IDO trigger (reassigns same-day jobs), SLA breach alert (X hours before DueDate → notify dispatcher), Work Order Completed → close Case + send CSAT survey, Maintenance Plan → Work Order generation

Configuration order matters: Skills before Service Resources (need skills to assign), Service Territories before Territory Members (need territory to assign member), Operating Hours before Service Resources (territory hours first), Work Types before Work Orders | Sandbox testing: always test scheduling engine in sandbox | Scheduling Policy: test with representative SA volume before production | Mobile settings: test on physical device | Permission sets: assign and test with each user type before go-live | Data migration: existing service records, assets, locations before go-live

Asset Management: Asset record (SerialNumber, Location, Status, InstallDate, WarrantyEndDate) | Service History: all Work Orders linked to Asset — visible on mobile | Maintenance Plans: recurring PM schedules linked to Asset | IoT integration: Salesforce IoT or external system sends asset sensor alerts → creates Case → creates Work Order on affected Asset | Asset 360: technician sees everything about the equipment before arriving | Work Order context: technician knows known issues, previous repairs, parts replaced

Automation: Record-Triggered Flow on Case (AfterUpdate or AfterInsert) | Trigger criteria: Case.Type = Field Service OR Case.Priority = Critical | Flow actions: create Work Order (linked to Case, Account, Contact, Asset), create Service Appointment (with DueDate from Entitlement SLA), invoke scheduling engine via Apex action | Apex alternative: Case trigger → WorkOrderService.createWorkOrder() | Entitlement: use Case Entitlement to set SA Priority and DueDate automatically

FSL.ScheduleService.schedule(SA Id, Policy Id) — schedules one SA | FSL.ScheduleService.scheduleBulk(List SA Ids, Policy Id) — schedules multiple SAs | Returns: FSL.ScheduleResult with isSuccess, scheduledResource, scheduledStart, scheduledEnd | Error handling: check isSuccess and handle failures | Policy ID: query Scheduling Policy record | Callout: scheduling engine is external (Heroku) — called as HTTP callout — must be in async context (future, queueable) | Test: mock FSL scheduling in tests using FSL.ScheduleServiceTest

Key methods: schedule(SaId, PolicyId) — schedules one SA | scheduleBulk(SaIds, PolicyId) — schedules multiple SAs | getAppointmentCandidates(SA, Policy) — returns eligible technicians without assigning | getAppointmentSlots(SA, Policy) — returns available time slots without assigning | All methods: return FSL.ScheduleResult or List | Async: must call in async context (HTTP callout to external engine) | Error handling: always check FSL.ScheduleResult.isSuccess | License required: FSL Scheduling permission required for running user

Integration patterns: MuleSoft (most common for FSL-ERP), direct REST API, Platform Events | Data flows: FSL → ERP (completed Work Orders for billing, TimeSheet data for payroll, ProductConsumed for inventory depletion) | ERP → FSL (Asset master data, parts inventory levels, customer entitlement contracts) | Real-time: Platform Events for critical data (Work Order Completed → ERP invoice trigger) | Batch: nightly ETL for inventory sync and timesheet export | Objects: ProductConsumed, TimeSheet, WorkOrder

FSL Mobile communication: standard Salesforce REST API for data sync | Offline protocol: FSL proprietary sync manages offline queue and conflict resolution | Custom mobile pages: LWC components embedded in FSL Mobile via Mobile Flow or Lightning App Builder | FSL Mobile SDK: for building custom native mobile apps that integrate with FSL backend | Real-time updates: long polling or Streaming API for Dispatcher Console updates | Location API: FSL Mobile uses device GPS and reports location via Salesforce Streaming API

Before scheduling: Flow validates SA data completeness before invoking scheduling engine | Custom filtering: Flow pre-filters eligible technicians based on custom criteria (e.g., customer preference stored on Account) | After scheduling: Flow triggers customer notification, updates SA custom fields, logs scheduling decision | Invocable actions: call FSL.ScheduleService from Apex → trigger Flow after result | Custom scheduling UI: Screen Flow in Dispatcher Console for complex dispatch decisions | Integration: Flow calls external API to check real-time parts availability before scheduling

Scheduled Apex patterns for FSL: GlobalOptimizationScheduler (nightly 2AM — optimizes next 3 days), InDayOptimizationScheduler (every 2 hours 8AM-6PM — reoptimizes current day), MaintenancePlanGenerator (nightly — creates upcoming PM Work Orders), SLABreachAlertScheduler (hourly — checks approaching DueDates), ResourceAbsenceAlerter (daily — checks upcoming capacity gaps) | Implementation: Schedulable interface + CronTrigger | Queue: up to 100 scheduled Apex jobs

IoT integration patterns: Salesforce IoT Cloud (native), AWS IoT via Platform Events, Azure IoT Hub via MuleSoft | Flow: Sensor alert → IoT platform → Platform Event to Salesforce → Flow creates Case + Work Order + SA → scheduling engine dispatches technician | Threshold: IoT platform filters noise — only significant anomalies create Cases | Asset linking: IoT device ID maps to FSL Asset record for context | Predictive: ML models on IoT data predict failure before threshold — proactive dispatch 24-48 hours ahead

FSL strengths: native Salesforce integration, no separate platform, standard Salesforce DevOps, tighter Service Cloud + CRM integration, lower total cost for Salesforce-heavy orgs | ServiceMax strengths: deeper FSL-specific features, more mature FSL capabilities, better for complex IoT/connected field service, stronger manufacturing focus | Trend: Salesforce investing heavily in FSL — gap is narrowing | Decision: FSL for standard field service, ServiceMax for complex industrial with advanced requirements

Emergency scheduling Apex pattern: (1) Create SA with Priority=Critical, EarliestStartTime=Now, DueDate=Now+4hours; (2) In @future method: FSL.ScheduleService.schedule(saId, emergencyPolicyId); (3) Check result.isSuccess; (4) If true: update SA.Status=Dispatched; (5) If false: Chatter post to dispatcher emergency queue; | FSL.ScheduleService.schedule is async — cannot be called from triggers directly | Emergency Policy: Work Rules only Match Skills + Territory, Service Objective: Minimize Travel 100%

Dispatcher Console LWC: add custom panels, maps overlays, KPI dashboards | FSL Mobile LWC: embed in Mobile Flow for guided technician workflows, device integrations, custom data capture | Record page LWC: Work Order custom components (asset history timeline, parts availability check) | Wire adapters: use @wire with FSL Apex controllers to fetch FSL data | Mobile considerations: LWC embedded in mobile must be lightweight, offline-tolerant | FSL Mobile Flow: primary mechanism to embed LWC in FSL Mobile

SLA setup: Entitlement on Case → DueDate auto-calculated on SA (DueDate = Case CreatedDate + Entitlement Response Time) | Monitoring Flow: scheduled hourly, queries SAs where DueDate < NOW+2hours AND Status != Completed → sends Chatter alert | Breach tracking: custom field on SA (SLABreached__c) set by Flow when SA Completed after DueDate | Reporting: SLA Compliance by Territory, Priority, Technician, Work Type | CRMA: real-time SLA dashboard with drill-down | Escalation: 2 hours before DueDate → Dispatcher notified; at DueDate → Dispatcher Manager notified

FSL test data setup: OperatingHours → ServiceTerritory → WorkType → ServiceResource (linked to test User) → ServiceTerritoryMember → WorkOrder → ServiceAppointment | Scheduling engine mock: use FSL.ScheduleServiceTest.setScheduleCalloutMockResponse() or stub with mock framework | Governor limits: FSL triggers may consume some DML — plan accordingly | Apex test coverage: all custom triggers and Apex on FSL objects must have 75%+ coverage | Callout mock: scheduling engine is external callout — must use mock in tests | Test isolation: create all FSL records in test setup

Indexed fields on SA: ServiceTerritoryId, Status, SchedStartTime, DueDate — always include in WHERE clause | Batch Apex: process 1,000+ SAs in batches (Maintenance Plan generation, bulk status updates) | Platform Events: high-volume IoT events — don't create Cases directly, use Platform Events + triggered Flows | Async scheduling: never call FSL.ScheduleService from synchronous context | CRMA: 1M+ SA records — use CRMA for all analytics, not SOQL reports | Archiving: archive Completed SAs older than 2 years to custom archive object

Self-service portal: Experience Cloud site | Customer appointment booking: getAppointmentSlots() returns available windows → customer selects → SA created | Real-time tracking: SA status and technician GPS location displayed on portal | Service history: customer sees their past Work Orders and service reports | Service request submission: customer creates Case → auto-converted to Work Order + SA | Security: customer sees only their own data (sharing rules) | Mobile-responsive: portal accessible on customer phone

Configuration: Maintenance Plan → set Frequency (Every 3 Months), FrequencyType (Months), GenerationTimeframe (2), WorkType (Preventive Maintenance), Asset | Trigger: Maintenance Work Order Completion → FSL generates next Work Order | Generation: controlled by GenerationTimeframe — creates that many future Work Orders ahead | Scheduling: generated Work Orders can be auto-scheduled via Scheduling Policy | Apex trigger: custom logic can modify generated Work Orders before scheduling | Compliance: PM completion rate reported for regulatory compliance

Utilization calculation: Productive Hours (travel + on-site) / Available Hours (Operating Hours) | Data source: Time Sheets (actual) or SA scheduled times (planned) | Categories: On-Site time, Travel time, Admin time, Idle time | Target: 70-80% utilization (below = underutilized, above = risk of burnout/quality issues) | CRMA dashboard: utilization by technician, territory, day of week, Work Type | Action: rebalance territory assignments if persistent imbalance

FSL Scheduling: assigns Service Appointments to field technicians | Omni-Channel: routes Cases, Chats, Emails to contact center agents | Key difference: FSL considers travel time and geographic scheduling; Omni-Channel does not | Both: skill-based routing, capacity management | Combined: Case created → Omni-Channel routes to agent → agent creates Work Order → FSL schedules technician → field job completed → Case closed | Different routing algorithms: FSL optimization engine vs Omni-Channel routing rules

FTFR: Work Orders with only 1 SA and status=Completed / Total Work Orders | MTTR: AVG(SA Completed DateTime - Work Order Created DateTime) | SLA Compliance: SA where Completed Date <= DueDate / Total SAs | Utilization: SUM(SA Duration) / SUM(Operating Hours) per technician | CSAT: survey sent post-completion, linked to Work Order | Cannot Complete Rate: SAs with Status=Cannot Complete / Total SAs | Travel Time %: SUM(travel time blocks) / SUM(total shift time) | CRMA: all KPIs in pre-built Field Service Analytics dashboard

Approach 1: Multiple SAs on one Work Order — best for jobs where each day is distinct (Day 1: survey, Day 3: removal, Day 5: installation) | Approach 2: Single SA with long duration — for continuous multi-day jobs (blocking technician calendar for 3 consecutive days) | Approach 3: WOLI-based SAs — each major phase has own WOLI with own SA and skills | Scheduling: multi-day SA blocks technician calendar for full duration | Dependencies: SA2 start requires SA1 completion — configure SA dependency | Project jobs: complex multi-week jobs often use Work Order Line Items with separate SAs per phase

Scale considerations: custom indexes on SA (ServiceTerritoryId, Status, SchedStartTime), Resource Optimization add-on for 1,000+ technicians, Platform Events for IoT meter alerts, batch Apex for PM Work Order generation | Territory model: 5 regions → 20 states → 200 zones | Skills: Electrical, High Voltage, Meter Reading, Transformer, Substation | Maintenance Plans: all 50,000 network assets | Dispatcher model: 200 zone dispatchers + 20 regional dispatchers + 5 national operations managers

Location hierarchy: Building (parent) → Floor → Unit (child Locations) | Asset per unit: each AC unit, fire system, elevator = separate Asset | Bundling: all units in one building needing quarterly maintenance = Appointment Bundle (one technician visit) | Route optimization: Scheduling Policy considers floor-level sequencing within building | Work Order per unit: one Work Order per Asset, bundled into one SA | Service Report: per unit service report generated automatically

Mistake 1: incomplete Scheduling Policy (only 1 Work Rule, no Service Objectives) → technicians assigned randomly | Mistake 2: no Operating Hours → engine schedules at 2AM | Mistake 3: no skill expiry dates → non-certified technicians assigned to regulated jobs | Mistake 4: no offline testing → technicians stuck at sites without connectivity | Mistake 5: no HR integration → absent technicians still receiving jobs | Mistake 6: not using Work Types → each Work Order manually configured → inconsistent durations and skills

Compliance use cases: electrical safety (High Voltage certification mandatory — FSL enforces via Work Rules), gas safety (Gas Safe certification required), medical equipment (FDA-regulated service documentation), elevator maintenance (mandatory annual inspection compliance), ISO maintenance records | Audit trail: SA status timestamps + technician ID + GPS location | Document retention: service reports stored on Work Order (configurable retention period) | Regulatory reports: CRMA compliance dashboards (% assets with current certifications, inspection completion rate)

Components: Experience Cloud site, Apex controller calling FSL.ScheduleService.getAppointmentSlots(), Screen Flow for booking wizard, SA creation on slot selection, confirmation email Flow, day-of status notification Flow, CSAT survey post-completion | Slots returned: configurable number of options (typically 3-5 windows over next 3-7 days) | Rescheduling: customer can reschedule via portal up to 24 hours before appointment | Cancellation: customer cancels → SA cancelled → capacity freed in FSL

Telecom specifics: customer time windows mandatory (EarliestStartTime/DueDate for morning/afternoon slots), Skills: Fiber, Cable, Network, Antenna | Assets: CPE Equipment per customer (router serial number) | High volume: Resource Optimization add-on for 500+ technicians | Integration: network provisioning system (BSS/OSS) → Platform Event → Work Order creation on order activation | Failed installation: Cannot Complete → auto-create follow-up + send engineer | SLA: installation within 48 hours, fault repair within 24 hours

Policy design principles: Emergency Policy (Work Rules: Skills + Territory only; Service Objective: Minimize Travel 100%); Standard Policy (Work Rules: Skills + Territory + Working Hours; Service Objectives: balanced — Travel 50%, Skill Match 30%, Customer Window 20%); Maintenance Policy (Work Rules: Skills + Territory; Service Objectives: Travel 70%, Workload Balance 30%) | Tuning: adjust Service Objective weights based on actual KPI data | Never: leave Service Objectives empty (engine has no optimization goal) | Review: monthly policy performance review

Migration steps: data mapping workshop (legacy field → FSL field), historical WO migration (External IDs for deduplication), Asset migration (serial numbers → Asset records), Location geocoding (convert addresses to lat/long for FSL map), skill migration (legacy certifications → FSL Skills), Service Resource creation (link to new Salesforce User records) | Parallel operation: critical for dispatcher confidence | Training: FSL Mobile training for all technicians (1 day each) | Cutover: weekend go-live, support team on standby

Entitlement Template: defines default SlaType, BusinessHours, MilestoneType | Applied: when creating new Entitlement from a contract or manually | Consistency: all Gold customers get identical SLA terms | Automation: Flow auto-creates Entitlement from Template when new customer contract is activated | SLA tiers: Gold Template (4-hour response, premium BusinessHours), Silver Template (8-hour, standard BusinessHours), Bronze Template (24-hour, standard BusinessHours) | Impact on FSL: Entitlement drives SA DueDate = creation + response time

Healthcare specifics: FDA regulated service → Work Rules enforce specific technician certifications | 21 CFR Part 11: service records (Interaction Summaries equivalent — service reports) must be immutable, timestamped, and auditable | Planned maintenance: Maintenance Plans with zero deviation from schedule | Preventive maintenance compliance: 100% completion required (patient safety) | Equipment quarantine: if maintenance missed → Asset Status = Quarantined (Flow) | Emergency: medical equipment failure = Critical Priority SA → 2-hour response SLA | Documentation: service report includes calibration readings, test results, technician license number

Knowledge article types: Troubleshooting Guide (symptom → diagnosis → fix), Installation Manual (step-by-step), Safety Procedure (mandatory pre-work checklist), Wiring Diagram (technical reference), Product Bulletin (known issues, fixes) | Linking: Work Type → Knowledge articles (automatically shown for that job type), Asset → Knowledge articles (product-specific) | Offline: articles pre-downloaded when SA dispatched | Mobile search: technician searches from FSL Mobile | Article feedback: technician flags outdated article → creates Knowledge review task for technical author

CRMA dataset: ServiceAppointment with refresh schedule (15 min for near real-time) | Key charts: SA status donut (by status), SLA compliance bar (by territory), Utilization gauge (by technician group), Response time trend (emergency SA creation to dispatch), Completion rate vs target | Live updates: Salesforce Reports refresh on page refresh, CRMA scheduled dataset refresh | Filters: territory, date, priority, technician | Mobile: CRMA mobile app for manager visibility on the go

Callout limits: FSL.ScheduleService uses HTTP callout to Heroku — must be async | Bulk scheduling: scheduleBulk(List saIds, policyId) = 1 callout for up to 25 SAs | SOQL limits: FSL triggers add SOQL queries — monitor with Developer Console | DML limits: FSL managed package triggers consume DML rows | Performance: always filter SA SOQL by ServiceTerritoryId (indexed) | Optimization: Global Optimization is async (background job) — not subject to transaction limits | Testing: test with production-representative data volumes in sandbox

VIP implementation: Gold Entitlement → SA DueDate = 2 hours | Preferred Resource: Account.FSL_Preferred_Technician__c → auto-populate SA Preferred Resource on creation | Dedicated zone: VIP Service Territory zone with 5 dedicated senior technicians | Priority: all VIP SAs = Critical | Dispatcher alert: Flow on VIP SA creation → immediate Chatter alert to VIP dispatcher | On-call: VIP on-call technician Resource Absence = never (24/7 availability) | CSAT: separate VIP CSAT survey with dedicated tracking

FSL Consultant certification: FSL-specific knowledge exam | Prerequisites: Admin + Service Cloud Consultant recommended | Trailhead: Field Service Specialist Superbadge + Field Service Trailmix | Exam topics: FSL data model, scheduling, optimization, mobile, integration | Career path: Service Cloud Consultant → FSL Consultant → FSL Architect | Salary premium: FSL is niche — fewer certified consultants = higher compensation | Interview: hands-on configuration test common (configure Scheduling Policy, Work Type, dispatch SA)

Cannot Complete Flow: SA Status = Cannot Complete AND Reason Code selected → (1) Create follow-up SA (same Work Order, scheduled next 24-48 hours); (2) Update Work Order Status = On Hold; (3) Customer notification SMS/email with reschedule date; (4) Dispatcher Chatter alert with reason and new SA link; (5) Log reason on custom field for analytics | Reason codes: Parts Unavailable, Customer Not Present, Access Denied, Safety Concern, Equipment Issue | Cannot Complete analytics: monthly report drives root cause initiatives

When needed: 100+ technicians, 500+ SAs/day, complex objectives (multi-skill, customer windows, crew coordination), high-value SLA penalties (optimization quality matters financially) | Benefits vs standard: handles massive volumes without degradation, ML learns technician performance patterns, 5-15% improvement in optimization quality, predictive scheduling reduces last-minute changes | Cost: additional license cost — ROI justification: fuel savings + SLA compliance improvement | Setup: enable in FSL settings + configure optimization job schedule

Q1-2: FSL architecture and scheduling policy | Q3-4: FSL optimization and exception handling | Q5: FSL Apex development | Q6: FSL preventive maintenance | Q7: FSL-Service Cloud integration | Q8: FSL Mobile | Senior-level additions: Resource Optimization ROI, multi-territory enterprise architecture, IoT integration design, ERP integration patterns | Practical test: configure Scheduling Policy, create Work Type, dispatch SA in sandbox | Pass rate: 55% of Service Cloud consultants

Manufacturing specifics: planned maintenance within production downtime windows (EarliestStartTime/DueDate matching shift schedule), Skills: CNC, Hydraulics, Pneumatics, Electrical, Welding | Assets: every machine on factory floor with serial number | Spare parts: van stock for common parts + warehouse for complex parts | IoT: machine sensors → SCADA → Platform Event → proactive Work Order creation | ERP: SAP PM/MM integration (Work Orders → billing, parts consumed → inventory) | Safety: Work Permit system integration (permit required before SA can start)

Communication triggers: SA Dispatched → confirmation email/SMS, SA Status = En Route → ETA SMS, Geofence entry → arrived SMS, SA Status = Completed → service report email + CSAT survey, SA Status = Cannot Complete → reschedule notification | Channels: SMS (Salesforce SMS add-on or Twilio), Email (automated via Flow), Push notification (FSL Mobile for customer app) | Customer portal: real-time tracking on Experience Cloud | Personalization: technician photo and name in communications (builds trust)

Parts workflow: van ProductItems track current stock levels | ProductConsumed: technician records part used on WO from FSL Mobile (barcode scan) | Stock decrement: ProductConsumed decrements ProductItem quantity automatically | Low stock alert: Flow on ProductItem quantity < reorder point → create ProductRequest | Fulfillment: warehouse fulfills request → ProductTransfer from warehouse to van | Pickup vs delivery: technician picks up at depot OR warehouse delivers to technician (configurable) | Planning: weekly van audit compares actual vs system stock

Bundle Policy: FSL Configuration → Bundle Policies → define matching criteria | Matching criteria: same Location (exact), nearby Location (within radius), same Work Type, same time window (same day, same morning/afternoon slot) | Bundle SA: created as the parent appointment | Bundle Members: individual SAs linked to Bundle SA | Scheduling: Bundle SA is scheduled — all members inherit same resource and time | Member status: each member SA has own completion status | Use case: apartment complexes, office buildings, neighboring customer sites

Shift configuration: create Operating Hours for each shift pattern | Service Resource: assign to appropriate shift Operating Hours | Rotation: Scheduled Apex changes Service Resource Operating Hours assignment based on rotation schedule | Multiple shifts in one territory: Service Territory Operating Hours = 24 hours (widest window), individual resources constrained by their shift Operating Hours | Overtime: Resource Absence type = Overtime pre-approved hours extension | On-call: dedicated On-Call Operating Hours (evenings/weekends) for emergency coverage

Report types: Operational (daily — dispatchers), Tactical (weekly — managers), Strategic (monthly — leadership) | CRMA vs Reports: CRMA for >10K records, standard Reports for small operational lists | Automated delivery: scheduled reports emailed to stakeholders | Key dashboards: CRMA Field Service Analytics + custom KPI dashboard | Operational metrics: SAs by status, unscheduled queue, approaching DueDates | Tactical: SLA compliance, FTFR, utilization by territory | Strategic: MTTR trend, CSAT trend, cost per SA, PM compliance

Architecture components: Service Territory hierarchy (matches org structure), Resource Optimization (required at 500 technician scale), Integration hub (MuleSoft — ERP, IoT, HR), Analytics (CRMA FSA + custom dashboards), Self-service (Experience Cloud booking portal), Automation (Global Opt nightly, IDO hourly, SLA alerts), Governance (FSL Center of Excellence: 2 admins + 2 developers + 1 functional lead) | Phased rollout: Pilot (50 technicians) → Region 1 (150) → Region 2 (150) → Region 3 (150) | Timeline: 12 months

Agentforce FSL use cases: (1) Customer self-service scheduling agent (customer says I need my AC serviced → agent checks availability → books SA → confirms); (2) Disruption management agent (technician delayed → agent proactively reschedules affected customers → notifies dispatcher of changes); (3) Field technician AI assistant (technician asks How do I replace the impeller on Pump XYZ? → AI searches Knowledge + Asset history); (4) Predictive maintenance agent (analyzes IoT data trends → recommends proactive SA creation) | 2026: most FSL enterprise clients evaluating Agentforce for dispatcher automation

Seasonal preparation: 8-12 weeks before peak: review CRMA capacity forecast | Secondary members: senior technicians from low-season territories added as Secondary in high-season territories | Contractor resources: pre-created Service Resources for contractors (activate/deactivate as needed) | Extended Operating Hours: seasonal Operating Hours template (e.g., add Saturday full day) | Seasonal policy: relaxed Soft Boundaries Service Objective (cross-territory OK during peak) | Capacity vs demand chart: CRMA shows upcoming capacity gap — trigger for contractor activation

ERP integration: MuleSoft bidirectional — Work Orders to ERP for billing, Asset master from ERP to FSL, TimeSheets to payroll | IoT: IoT platform → Platform Event → Salesforce Flow → Case + Work Order creation | HR: approved leaves → Resource Absence creation (REST API or MuleSoft) | CRM: FSL native on Salesforce — no external CRM integration | Analytics: FSL data → Salesforce Data Pipelines → Snowflake → ML models → churn/failure prediction pushed back to FSL | Mapping: external IDs on all FSL objects for bidirectional sync

Core skills: FSL data model, Scheduling Policy design, Work Types, Maintenance Plans | Apex: FSL.ScheduleService async patterns, FSL test data factory, optimization trigger | Flows: Case-to-WO, SA status notifications, SLA breach alerts, Cannot Complete automation | CRMA: FSL KPI dashboards, Field Service Analytics app | Advanced: IoT integration (Platform Events), Agentforce scheduling agent, Resource Optimization configuration | Mobile: FSL Mobile customization, Mobile Flow, offline LWC | Certification: Salesforce Field Service Consultant required for senior roles

Preparation strategy: Trailhead Field Service Specialist Superbadge (mandatory), hands-on sandbox with real scheduling (create territories, resources, dispatch SAs), practice explaining Scheduling Policy design decisions, know FSL.ScheduleService async requirement cold, understand Global Optimization vs IDO triggers, prepare real examples of FSL implementations or projects | Interview question pattern: always explain with a scenario, not just definitions | Certification: Field Service Consultant exam before senior interviews