Field Service Architecture

Salesforce Field Service (formerly Field Service Lightning) manages mobile workforces from work order creation through scheduling, dispatching, mobile execution, and job completion. Designing solutions that scale for utilities, telecom, and manufacturing requires a solid grasp of the data model, scheduling engine internals, territory design trade-offs, and offline mobile architecture.

Architecture Overview

Figure 1. End-to-end Field Service architecture across five layers: Service Cloud provides the foundational Case and Account objects; the core FSL layer introduces Work Orders, Service Appointments, and Service Resources; the scheduling engine applies Work Rules and Service Objectives to assign appointments; and the mobile app with Briefcase delivers offline execution to technicians in the field.

Core Data Model

Field Service uses a combination of standard objects (native to the platform) and managed package objects (installed via the Field Service managed package). The relationships between these objects matter at the CTA level.

Key Objects and Relationships

Object	Type	Purpose	Key Relationships
Work Order	Standard	Describes work to be performed	Case, Account, Contact, Asset, Work Type
Work Order Line Item	Standard	Subtasks within a Work Order	Work Order (parent)
Service Appointment	Standard	Scheduled visit to perform work	Work Order, Service Resource, Service Territory
Service Resource	Standard	Individual technician or crew	User, Service Territory Member, Skill
Service Territory	Standard	Geographic region for dispatch	Parent Territory, Operating Hours
Service Territory Member	Standard	Links resource to territory	Service Resource, Service Territory
Work Type	Standard	Template for common job types	Defines duration, skills, auto-create SA
Skill	Standard	Competency (e.g., “Gas Certified”)	Skill Requirement, Service Resource Skill
Operating Hours	Standard	Business hours for territories/resources	Service Territory, Service Resource
Resource Absence	Standard	PTO, training, unavailability	Service Resource
Maintenance Plan	Standard	Recurring maintenance schedule	Asset, Work Type
Scheduling Policy	Managed Pkg	Rules + objectives for scheduling	Work Rules, Service Objectives
Time Sheet	Standard	Tracks technician labor time	Service Resource, Service Appointment

Object Relationship Chain

The critical relationship chain for scheduling is:

Case → Work Order → Service Appointment → Service Resource
                                        → Service Territory
         Work Type → (auto-creates SA with duration + skills)

CTA Insight

Work Type templates Work Orders with default duration, required skills, and auto-creation of Service Appointments. Always recommend Work Types to standardize job definitions across the organization.

Scheduling & Optimization Engine

The scheduling engine is the core of Field Service. It determines which technician gets which job, when, and in what order. Enhanced Scheduling and Optimization (ESO) is the modern replacement for the legacy managed package optimizer.

Scheduling Policy Components

A Scheduling Policy consists of two layers:

Layer	Purpose	How It Works
Work Rules (filters)	Eliminate unqualified candidates	Pass/fail - if a resource fails any work rule, they are excluded
Service Objectives (ranking)	Rank remaining candidates	Weighted scoring - higher weight = higher priority

Work Rules (Constraint Filters)

Work Rule	What It Does
Match Skills	Resource must have all required skills at the required level
Match Territory	Resource must be a primary or relocation member of the SA’s territory
Match Time	SA must be scheduled within its earliest start / due date window
Service Resource Availability	Resource must not have conflicts (absences, other SAs)
Maximum Travel from Home	Limits max distance or drive time from resource’s home base
Field Matching	Custom field-level match between SA and resource (e.g., language)

Service Objectives (Weighted Ranking)

Objective	What It Optimizes	Common Weight
Minimize Travel	Shortest drive time to job site	High
ASAP	Earliest available time slot	Medium-High
Preferred Resource	Favor a customer’s preferred technician	Medium
Minimize Overtime	Stay within standard working hours	Medium
Resource Priority	Prefer higher-priority resources	Low-Medium
Custom Objective	Apex-defined custom scoring logic	Varies

How Optimization Works

1. Collect data: gather all SAs within the optimization horizon, plus available resources, territories, and skills
2. Apply work rules: filter out unqualified candidates for each SA
3. Generate permutations: build thousands to millions of possible schedule arrangements
4. Score each permutation: grade against weighted service objectives
5. Select winner: the highest-scoring schedule becomes the result
6. Apply to Gantt: dispatcher reviews and approves, or auto-dispatch applies it

Optimization at Scale

The legacy optimizer struggles beyond ~500 resources per optimization run. Enhanced Scheduling and Optimization (ESO) supports up to 50,000 appointments with Dynamic Scaling. For enterprise deployments, always recommend ESO with territory-scoped optimization windows.

Enhanced Scheduling and Optimization (ESO)

ESO is Salesforce’s next-generation scheduling engine, replacing the legacy managed package optimizer:

Capability	Legacy Optimizer	ESO
Multi-day appointments	Not supported	Supported
Skills matching flexibility	Strict yes/no	OR-based, minimum levels
Scale	~500 resources per run	50,000+ appointments
Infrastructure	Managed package (Heroku)	Hyperforce-native
AI integration	None	Agentforce-ready

Territory Design

Territory design directly impacts scheduling performance, dispatcher usability, and optimization quality. Getting it wrong is one of the most common Field Service anti-patterns.

Hierarchy Structure

Figure 2. Sample four-level territory hierarchy for a national deployment: National root, Region, Metro District, and Dispatch Zone. Each leaf zone should contain no more than 50 technicians to keep optimization runs manageable and dispatcher workloads visible.

Territory Design Best Practices

Guideline	Recommendation	Why
Resources per territory	Max 50	Keeps optimization manageable; dispatchers can monitor effectively
Hierarchy depth	3-4 levels (Region > District > Zone)	Balances visibility with granularity
Territory boundaries	Never cross time zones	Operating Hours break if a territory spans time zones
Hierarchy max	500 territories per hierarchy	Platform limit
Optimization scope	Optimize per territory, not globally	Global optimization across thousands of resources is too slow
Membership type	Use Primary + Relocation members	Primary = home territory; Relocation = overflow from neighbors

Resource Membership Types

Type	Behavior
Primary	Resource’s home territory - scheduler checks this first
Secondary	Resource can be scheduled here but is deprioritized vs Primary
Relocation	Resource temporarily relocated - treated as Primary in new territory

Time Zone Trap

Never allow a service territory to span multiple time zones. Operating Hours are calculated against the territory’s time zone. A territory spanning Central and Eastern time will produce incorrect scheduling windows and confused technicians.

Mobile Architecture

The Field Service Mobile App is purpose-built for technicians working in the field. Its offline capabilities are significantly stronger than those of the standard Salesforce Mobile App.

Offline Data Flow

Figure 3. Offline data flow for Field Service Mobile showing the full lifecycle: admin-defined Briefcase rules prime records to the device, AES-256 encryption protects local data, the technician works offline with changes queued locally, and the app syncs bidirectionally when connectivity is restored.

Mobile Capabilities

Feature	Details
Briefcase Builder	Admin-defined rules for which records sync offline (by object, filters, related records)
Offline LWC	Lightning Web Components that work without connectivity
Mobile Flows	Screen flows optimized for mobile with offline support
Deep Linking	URL schemes to launch specific records or actions in the app
Knowledge Articles	Access troubleshooting guides offline
Barcode Scanning	Scan asset serial numbers, parts
Photo/Signature Capture	Attach proof-of-work images and customer signatures
Service Reports	Generate and email completion reports on-site
Geolocation	Real-time technician location tracking for dispatch

Offline Security

• Local data encrypted with AES-256 encryption
• iOS: per-app unique keys stored in iOS Keychain, protected by ECC-256 private key
• Android: keystore-backed encryption
• Remote wipe capability if device is lost or compromised
• Data is scoped per Briefcase - technicians only see what the admin configures

Briefcase Sizing

Keep record counts per user low (commonly cited best practice: 10,000-15,000 records; verify against current documentation). Broad Briefcase rules cause slow sync times and poor mobile performance. Filter aggressively. Technicians typically only need their upcoming 7 days of appointments plus related records.

Preventive Maintenance

Maintenance Plans automate recurring work order generation for asset-based service schedules.

Component	Purpose
Maintenance Plan	Defines frequency (monthly, quarterly, annually) and associated assets
Maintenance Asset	Junction linking a plan to one or more Assets
Work Type	Template for generated Work Orders (duration, skills, products)
Generated Work Orders	Auto-created WOs with Service Appointments ready for scheduling

Example: a plan covering 3 assets on a monthly schedule creates 3 Work Orders per month. Each inherits duration, skills, and products from the Work Type.

Agentforce for Field Service

Agentforce (formerly Einstein Copilot) is being integrated into Field Service for autonomous scheduling and job support:

Capability	Status (Spring 2026)	What It Does
Appointment Scheduling	GA	Customers self-schedule via natural language, 24/7
Schedule Gap Resolution	GA (verify current status in Salesforce release notes)	AI identifies and fills open slots automatically
On-Site Troubleshooting	GA	AI assists technicians with step-by-step guidance
Job Wrap-Up Summaries	GA (verify current status in Salesforce release notes)	Auto-generates service reports from job data
Proactive Scheduling	Pilot (verify current status in Salesforce release notes)	Predicts failures from IoT/asset data, pre-schedules visits

Agentforce Architecture

Agentforce for Field Service runs on Data Cloud (unifies structured + unstructured data) and the Atlas Reasoning Engine (AI reasoning layer). It ships with pre-built Topics and Actions that can be customized with guardrails. Dispatchers keep override control over all AI-generated schedules.

CTA Scenario Patterns

Scenario 1: National Utility Company (10,000+ Technicians)

Situation: A utility company with 12,000 field technicians across 50 states needs to manage emergency repairs, meter installations, and preventive maintenance for millions of assets.

Architecture decisions:

• Territory hierarchy: 4 levels - National > Region (8) > District (50) > Zone (200+). Keep zones under 50 technicians each
• Scheduling: ESO with Dynamic Scaling. Emergency work uses priority-based drip feed; planned work uses overnight global optimization
• Offline: Briefcase scoped to 3-day appointment window + related assets. Knowledge articles for safety procedures synced offline
• Integration: Real-time IoT telemetry from smart meters flows into Data Cloud, triggering proactive maintenance Work Orders
• Skills: Complex skill matrix - gas certification, electrical license, confined space, CDL - enforced via Match Skills work rule

Scenario 2: Telecom Provider (Installations + Repairs)

Situation: A telecom company manages fiber installations (4-8 hour jobs) and repair calls (1-2 hour emergency response) with 3,000 technicians.

Architecture decisions:

• Multi-day support: Fiber installations use ESO multi-day appointments spanning 2 days with crew scheduling
• Priority routing: Repair SLAs enforced via ASAP service objective with highest weight; installations use Minimize Travel
• Crew scheduling: Service Resources configured as crews (resource type = Crew) for complex installations requiring 2-3 technicians
• Contractor management: Third-party contractors as Service Resources with limited territory membership and restricted Briefcase access
• Customer self-service: Experience Cloud (formerly Community Cloud) portal with Agentforce for customer-initiated appointment scheduling and rescheduling

Scenario 3: Manufacturing Equipment Maintenance

Situation: A manufacturer maintains industrial equipment at 500 customer sites with 200 specialized technicians and strict SLA requirements.

Architecture decisions:

• Asset-centric model: Maintenance Plans per asset type with quarterly/annual frequencies. Work Types template required parts and skills
• Skill specialization: Deep skill hierarchy - CNC machines, hydraulic presses, robotic arms - each requiring specific certifications with skill levels (1-10)
• Parts management: Products Required on Work Orders linked to inventory tracked in Salesforce or integrated ERP
• SLA tracking: Milestones on Entitlements tied to Work Orders; custom escalation flows when SLA breach approaches
• Knowledge base: Technician-facing Knowledge articles with equipment manuals, wiring diagrams, and troubleshooting trees synced via Briefcase

Decision Guide: Field Service vs Alternatives

Figure 4. Qualification flowchart for recommending full Field Service versus the lighter Salesforce Scheduler. The key differentiators are workforce size above 10, the need for skills-based and territory-based scheduling optimization, and whether technicians require offline mobile access in the field.

Criteria	Salesforce Scheduler	Field Service	Custom Build
Workforce size	Small (<10)	Medium to enterprise (10-50,000+)	Any
Scheduling complexity	Simple time slots	Skills, territories, optimization	Unlimited
Offline mobile	No	Yes (Briefcase + FS Mobile)	Build your own
Asset management	No	Yes (Maintenance Plans)	Build your own
Dispatcher console	No	Yes (Gantt + Map)	Build your own
Optimization engine	No	Yes (ESO)	Third-party or custom
License cost	Lower	Higher (FS license per user)	Dev cost only
Time to value	Fast	Medium (config-heavy)	Slow

Key Limits & Gotchas

Platform Limits

• 500 territories per hierarchy
• 50 resources per territory (best practice, not hard limit)
• 10,000 Work Orders per hierarchy (community best practice, verify against current limits documentation)
• 10,000 child records per Work Order (line items + service appointments) (community best practice, verify against current limits documentation)
• Managed package deploys require careful sandbox testing - FSL managed package updates can break customizations
• Operating Hours are territory-scoped - never cross time zones
• Briefcase sync can be slow with large record counts per user (commonly cited best practice: keep under 10,000-15,000, verify against current documentation)
• Optimization runs are CPU-intensive - schedule during off-peak hours for large territories

Common Anti-Patterns

• Building custom scheduling logic in Apex instead of using Work Rules and Service Objectives
• Creating one giant territory with 500+ resources (optimization becomes unusable)
• Skipping Work Types and manually configuring every Work Order (inconsistency and admin burden)
• Ignoring Briefcase data scoping (syncing entire objects instead of filtered subsets)
• Running global optimization across all territories simultaneously (timeouts and poor results)

Related Topics

• Mobile Strategy: Broader mobile architecture including Briefcase, Mobile Publisher, and SDK options
• Licensing: Field Service license types and cost implications
• Org Strategy: Multi-org considerations for field service across business units
• Platform Capabilities: Governor limits and async patterns relevant to FSL triggers and automation
• Integration: Patterns for connecting FSL with ERP, IoT platforms, and external systems
• Data Architecture: Data volume considerations for Work Order and Service Appointment records

Sources

• Field Service Core Data Model - Salesforce Developer Guide (Spring ‘26)
• Field Service Scheduling and Optimization - Salesforce Help
• How Does the Field Service Optimization Engine Work? - Salesforce Help
• Enhanced Scheduling and Optimization - Salesforce Help
• Guidelines for Creating Service Territories - Salesforce Help
• Field Service Limits and Limitations - Salesforce Help
• Dispatcher Console - Salesforce Help
• Offline Briefcase for Field Service - Trailhead
• Preventive Maintenance - Trailhead
• Agentforce for Field Service - Salesforce Newsroom
• Service Territory Design - Salesforce Ben
• Scheduling Policies Overview - Trailhead
• Field Service Scheduling in the Agentforce Era - Salesforce Blog