Field service allocation runs on a small set of records. This page is the reference for each: where it is maintained, what it holds, and which allocation behaviour reads it — including the fields that are stored but read by nothing yet, so a configured value is never mistaken for an enforced one.
Where the building blocks live
Apart from queues, none of these records has a dedicated Setup screen; they are ordinary entity screens reached from the apps below, and the Setup Copilot or the Data API can maintain them as data.
| Record | Where to find it |
|---|---|
| Resources | Field Sales app → Resources (also listed in the Payroll and Rewards apps) |
| Resource Availability | Field Sales app → More → Resource Availabilities |
| Skills, Resource Skills, Skill Lines | CRM app → Settings → Skills tiles |
| Resource Groups | CRM app → Settings; also the Rewards app |
| Queues | CRM app → Queues, or Setup → Settings → Telephony → Queues |
| Resource Presence | Written by the agent's browser; readable as the Resource Presence entity |
| Appointment Types, Bookable Resources, Slot Templates | CRM app → Settings, where the appointment-scheduling module is enabled |
| Service Bays | Service app → Service Bays |
| Dispatch console | A widget placed on an app page by a designer (Field Sales → Allocation Console in the shipped model) |
| Location tracking | Setup → Model → Mobile app → Location tracking tab |
Resources and skills
A Resource is the person master: anyone who carries work. The fields allocation reads are Is Active, the linked User (routing refuses a resource with no user, because accepted work must end in an owner), Default Branch and Default Partner Account (used to scope the dispatch console), Business Hours, Type and Manager.
A Resource Skill is one competency held by one resource: a Name, an optional link to the Skill catalog, a Proficiency Level, Start Date and End Date, and Is Active. Three consumers read it differently:
| Consumer | What it reads |
|---|---|
| Queue routing (Skill model) | Name equals the requested skill and Proficiency Level is at least 1 — nothing else |
| Appointment candidate search | Is Active and the linked catalog Skill's name — no proficiency, no dates |
| Bay and technician allocation | Name, level and the start/end window, scored against the job's Skill Lines (the demand side: one skill a job requires at a minimum level) |
The Skill catalog carries a name, description and a free-text routing Policy hint; queue routing does not read the catalog at all.
Resource groups
A Resource Group is a named pool with Resource Group Member rows. In field service it is the queue's agent pool and one of the dispatch console's scope chips; the same entity is also used by Rewards for incentive groups (Resource Group Type Scheme or Incentive), so keep field-service pools clearly named.
Queues and presence
A Queue holds the routing configuration. Administrators maintain queues under Setup → Settings → Telephony → Queues; the New queue dialog is the whole record:
| Field | Meaning |
|---|---|
| Name, Description | Identification |
| Routing model | Direct, Round robin, Load balance (the default when blank) or Skill-based — see work routing |
| Channels | The channel types this queue serves (Voice, Email, Chat, SMS, messaging, Web). Recorded on each work item; the route itself does not validate the channel against this list |
| Agent pool | The resource group whose members are the candidates |
| Active | Feeds membership checks and the supervisor snapshot; the route service does not refuse a route that names an inactive queue, so also stop rules and telephony routes from targeting it |
Resource Presence is one row per resource, written by the agent's own browser: Status (Available, Busy, Away, Offline — only Available receives pushed work), a Status Reason, and Max Work Items (default 5), the load ceiling routing enforces. Presence is a lease renewed every minute; a row not renewed for five minutes is treated as Offline. There is no setup screen for presence; adjust Max Work Items on the record where a resource should carry more or fewer concurrent items.
Appointment types and bookable resources
These records belong to the appointment-scheduling engine described in Resource availability and slot holds. The engine's API is live, but no shipped web or mobile screen books through it yet, so configure them when you are building on that API and treat the "read by" column as the current truth.
An Appointment Type defines a bookable kind of work:
| Setting | Read by |
|---|---|
| Default duration (30 minutes), buffer before/after | Availability and the resource claim: buffers extend every claim so back-to-back bookings stay apart |
| Resource requirements (JSON: role, kind, skill name, asset category, bay type, count, mandatory) | Candidate search and claiming; malformed JSON reads as no requirements |
| Minimum lead time, maximum advance days | The availability query trims what is offered |
| Cancellation cutoff, maximum reschedules | Appointment cancel/reschedule validation |
| Overbook percent | Applied when slots are released: the allowance is ceil(capacity × percent / 100) on each slot |
| Auto no-show after (minutes) | The appointment maintenance sweep |
| Location modes allowed (Branch, Onsite, Virtual) | Appointment validation |
| Requires customer confirmation, reminder offsets, applicable entities | Stored only — no code reads them yet |
A Bookable Resource registers one schedulable unit — exactly one of a person (a Resource), an asset, or a facility (a Service Bay) — with Kind, home Branch (empty means organization-wide), Concurrent Capacity (at least 1), Is Active and an effective window. Its Business Hours reference is stored but read by nothing; working hours are not applied to candidates. Bay and technician allocation create bookable-resource rows automatically for bays and technicians they allocate, so you will see rows appear without anyone creating them.
Service bays
A Service Bay is a physical workshop position. Fields: Name, Branch, Service Bay Type (Van, Plant, Workshop, Bin, Pallet, Washing Bay, Regular Bay, VHC Bay), Allow Inventory (the bay can hold stock), Is Active, and the occupancy settings the bay allocator reads: Allocation Mode (Vehicle, Labour or Both), Vehicle Capacity and Labour Capacity (default 1 each), Auto Release After (minutes), Occupancy Stretch Percent and Turnaround Minutes. The type is what an appointment requirement's bay type narrows on. Bay allocation from service orders and time sheets is documented under Service time sheets.
The dispatch console
The console is the AllocationConsole widget, placed on an app page by a designer — one page per work entity. Its design-time properties, by exact name:
| Property | Effect |
|---|---|
entity, labelField | The work entity and its display field |
assignField | The lookup to the resource that a Board or Gantt drop writes |
scheduleStartField, scheduleTimeField | The date (and optional separate time) field a Gantt drop and Optimize day set; without scheduleStartField drops only reassign and Optimize day does nothing |
durationField | Duration in minutes; items without one get a 90-minute block |
statusField, closedStatuses | Hide items in closed statuses (default: completed, cancelled, closed, expired, rejected) |
branchField, partnerField, accountGroupField | Fields the scope chips filter on |
geoMode, geoPointField, geoLookupField, geoRelatedEntity, geoRelatedPointField | Location configuration — a coordinate field on the entity, or a lookup to a record that carries one. Without it the Map view is unavailable |
stopsEntity, stopsParentField, stopsSequenceField, stopsAccountField | Child stops plotted on the Map |
views | Which of map, gantt, board to offer |
scopeChips | Which of partner, branch, resources, resourceGroup, accountGroup to show |
refreshSeconds | Auto-refresh interval; values under 5 are ignored |
itemNoun, itemNounPlural, title, subtitle | Wording |
Live positions come from the location-tracking service, not from the work entity. Operating the console is covered in The dispatch console.
Location tracking
Under Setup → Model → Mobile app, open the mobile app record and its Location tracking tab:
| Setting | Default | Meaning |
|---|---|---|
| Enable location tracking | Off | Off or absent means the app never asks for background location and check-in is not gated on it |
| Capture interval | 60 seconds (minimum 30) | How often a fix is recorded while checked in |
| Batch size | 20 points (1–200) | Fixes uploaded per request |
| Minimum distance | 25 metres (0 reports every fix) | Movement required before a new fix is recorded |
Behaviour and the privacy posture are documented in Location and the travelled path.
Automatic assignment
Owner-stamping on Lead, Opportunity and Product Demo inserts is configured on Partner Resource records — sequence, success criteria and rules — and documented in Automatic owner assignment, including the shipped picklist mismatches that stop the criteria from evaluating.
Common questions
Why must a resource be linked to a user account?
Because allocation ends in ownership, and ownership belongs to users. Routing drops a resource with no linked user before any other check, since work it accepted could never stamp an owner.
One pool of people, both routing and booking — do I configure them twice?
The person is one Resource record, but the engines read different registrations: routing reads resource-group membership, presence and Resource Skill name/level; the appointment engine reads a Bookable Resource with branch, capacity and effective window plus active skills by catalog name; bay allocation reads Skill Lines against Resource Skills with dates. A technician who should be routable, bookable and bay-allocatable needs all three kept in step.
A field on one of these records has no effect — is it broken?
Check the "read by" notes above first. Requires customer confirmation, reminder offsets, applicable entities and the bookable resource's business hours are stored for a later phase and are not enforced today; documenting them as live would be wrong.