Field Service Architecture

Salesforce Field Service (formerly Field Service Lightning) provides an end-to-end platform for managing mobile workforces — from work order creation through scheduling, dispatching, mobile execution, and job completion. The CTA must understand the data model, scheduling engine internals, territory design trade-offs, and offline mobile architecture to design solutions that scale for utilities, telecom, and manufacturing scenarios.

Architecture Overview

flowchart TD
    subgraph ServiceCloud["Service Cloud Foundation"]
        CASE["Case"]
        ACCT["Account"]
        ASSET["Asset"]
    end

    subgraph CoreFSL["Field Service Core"]
        WO["Work Order"]
        WOLI["Work Order<br/>Line Item"]
        SA["Service Appointment"]
        SR["Service Resource"]
        ST["Service Territory"]
        STM["Service Territory<br/>Member"]
        SKILL["Skill"]
        WT["Work Type"]
    end

    subgraph ScheduleEngine["Scheduling & Optimization"]
        SP["Scheduling Policy"]
        WR["Work Rules"]
        SO["Service Objectives"]
        OPT["Optimization Engine<br/>(ESO)"]
    end

    subgraph DispatchMobile["Dispatch & Mobile"]
        DC["Dispatcher Console<br/>Gantt + Map"]
        MA["Field Service<br/>Mobile App"]
        BC["Briefcase<br/>(Offline)"]
    end

    subgraph Maintenance["Preventive Maintenance"]
        MP["Maintenance Plan"]
        MWO["Generated<br/>Work Orders"]
    end

    CASE -->|creates| WO
    ACCT --> WO
    ASSET --> MP
    WO --> WOLI
    WO --> SA
    SA --> SR
    SR --> STM
    STM --> ST
    SR --> SKILL
    WT --> WO
    SP --> WR
    SP --> SO
    SP --> OPT
    OPT -->|assigns| SA
    MP -->|generates| MWO
    DC -->|dispatches| SA
    MA -->|executes| SA
    BC -->|offline data| MA

    style ServiceCloud fill:#264653,color:#fff
    style CoreFSL fill:#2a9d8f,color:#fff
    style ScheduleEngine fill:#e76f51,color:#fff
    style DispatchMobile fill:#457b9d,color:#fff
    style Maintenance fill:#6a4c93,color:#fff

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). Understanding these relationships is fundamental for CTA-level architecture.

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 is the architect’s best friend — it 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 heart of Field Service. It determines which technician gets which job, when, and in what order. Salesforce now offers Enhanced Scheduling and Optimization (ESO) as 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

Collect data — all SAs within the optimization horizon, all available resources, territories, and skills
Apply work rules — filter out unqualified candidates for each SA
Generate permutations — build thousands to millions of possible schedule arrangements
Score each permutation — grade against weighted service objectives
Select winner — the highest-scoring schedule becomes the optimized result
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. Poor territory design is one of the most common Field Service anti-patterns.

Hierarchy Structure

flowchart TD
    ROOT["National Operations<br/>(Root Territory)"]
    ROOT --> R1["West Region"]
    ROOT --> R2["Central Region"]
    ROOT --> R3["East Region"]

    R1 --> D1["San Francisco Metro"]
    R1 --> D2["Los Angeles Metro"]
    R2 --> D3["Chicago Metro"]
    R2 --> D4["Dallas Metro"]
    R3 --> D5["New York Metro"]
    R3 --> D6["Atlanta Metro"]

    D1 --> Z1["SF - North"]
    D1 --> Z2["SF - South"]
    D5 --> Z3["NYC - Manhattan"]
    D5 --> Z4["NYC - Brooklyn"]

    style ROOT fill:#264653,color:#fff
    style R1 fill:#2a9d8f,color:#fff
    style R2 fill:#2a9d8f,color:#fff
    style R3 fill:#2a9d8f,color:#fff

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, with robust offline capabilities.

Offline Data Flow

sequenceDiagram
    participant SF as Salesforce Org
    participant BC as Briefcase Rules
    participant APP as FS Mobile App
    participant TECH as Technician

    SF->>BC: Define offline data scope
    BC->>APP: Prime records on sync
    APP->>APP: Encrypt local store (AES-256)
    TECH->>APP: Works offline (view, create, edit)
    APP->>APP: Queue changes locally
    Note over APP: Connectivity restored
    APP->>SF: Sync changes back
    SF->>APP: Confirm + pull updates

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 minimal per user (commonly cited best practice: 10,000-15,000 records, verify against current documentation). Overly broad Briefcase rules cause slow sync times and poor mobile performance. Use filters aggressively — technicians typically need only their upcoming 7 days of appointments plus related records.

Preventive Maintenance

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

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

Generation logic: if a plan covers 3 assets on a monthly schedule, the system creates 3 Work Orders per month, each inheriting duration, skills, and products from the Work Type.

Agentforce for Field Service

Salesforce is integrating Agentforce (AI agents) 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 is powered by Data Cloud (unifies structured + unstructured data) and the Atlas Reasoning Engine (AI reasoning layer). It uses pre-built Topics and Actions that can be customized with guardrails. Dispatchers retain 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 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

flowchart TD
    Q1["Do you dispatch a<br/>mobile workforce?"]
    Q1 -->|No| ALT1["Use Salesforce Scheduler<br/>or custom solution"]
    Q1 -->|Yes| Q2["More than 10<br/>technicians?"]
    Q2 -->|No| ALT2["Salesforce Scheduler<br/>may suffice"]
    Q2 -->|Yes| Q3["Complex scheduling?<br/>Skills, territories,<br/>optimization needed?"]
    Q3 -->|No| ALT3["Salesforce Scheduler<br/>+ basic Work Orders"]
    Q3 -->|Yes| Q4["Offline mobile<br/>required?"]
    Q4 -->|No| FSL1["Field Service<br/>without mobile app"]
    Q4 -->|Yes| FSL2["Full Field Service<br/>+ Mobile App + Briefcase"]

    style ALT1 fill:#e76f51,color:#fff
    style ALT2 fill:#e9c46a,color:#000
    style ALT3 fill:#e9c46a,color:#000
    style FSL1 fill:#2a9d8f,color:#fff
    style FSL2 fill:#264653,color:#fff

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)

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

Field Service Architecture

Architecture Overview

Core Data Model

Key Objects and Relationships

Object Relationship Chain

Scheduling & Optimization Engine

Scheduling Policy Components

Work Rules (Constraint Filters)

Service Objectives (Weighted Ranking)

How Optimization Works

Enhanced Scheduling and Optimization (ESO)

Territory Design

Hierarchy Structure

Territory Design Best Practices

Resource Membership Types

Mobile Architecture

Offline Data Flow

Mobile Capabilities

Offline Security

Preventive Maintenance

Agentforce for Field Service

CTA Scenario Patterns

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

Scenario 2: Telecom Provider (Installations + Repairs)

Scenario 3: Manufacturing Equipment Maintenance

Decision Guide: Field Service vs Alternatives

Key Limits & Gotchas

Related Pages

Sources