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 and assignment rules, 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, Rewards and Platform apps) |
| Resource Availability | Not in a standard app: the Resource Availability tab on a Resource record shows the calendar. Add the list to an app to open the records (see Mobile attendance) |
| Skills, Resource Skills | Support app → Settings → Skills and Resource Skills cards |
| Resource Groups | Support app → Settings → Resource Groups; also Rewards app → Resource Groups |
| Queues | Support app → Settings → Queues, CRM app → Settings → Queues, or Setup → Feature Hub → Service → Telephony → Queues |
| Resource Presence | Written by the agent's browser; readable as the Resource Presence entity |
| Appointment Types, Bookable Resources, Slot Templates | Not in any shipped app; add them to an app (Setup → Design Studio → Apps) where you build on the appointment-scheduling engine |
| Service Bays | Service app → Settings → Workshop Operations → Service Bays |
| Dispatch console | A widget placed on an app page by a designer. Shipped pages: Support → Case Allocation, Service → Allocation Console, Service → Settings → Service Order Dispatch and CRM → Lead Allocation; the visit-plan Allocation Console (its Field Sales menu entry is switched off) and Demo Allocation ship without a menu entry |
| Assignment rules | Setup → Process Studio → Assignment Rules (none shipped); Partner Resource rules for Lead, Opportunity and Product Demo inserts |
| Location tracking | Setup → Design Studio → Apps → Mobile Apps → the app's 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. New rows are named from the RS number series, so rename them before relying on this |
| Assignment rules | Active, within the start/end window, at or above At proficiency when set; the skill name may match the row's name or the linked Skill's name, ignoring capitals |
| Appointment candidate search | Is Active and the linked catalog Skill's name — no proficiency, no dates |
| Technician allocation (Time Sheet on a service order) | The linked Skill, Is Active, the start/end window and the level, checked against the work item'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 Policy note; nothing reads the description or policy, and queue routing does not read the catalog at all. Step-by-step setup is on Skills, resource skills and skill requirements.
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. Resource Group Type is a label only, and membership is always added by hand or by import. See Resource groups for the full procedure.
Queues and presence
A Queue holds the routing configuration. Administrators maintain queues under Setup → Feature Hub → Service → Telephony → Queues (or as records under Support → Settings); 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, menu entry or form for presence. To let a resource carry more or fewer concurrent items, change Max Work Items through the data API, as described in Agent presence.
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. Setting up bays, their capacities and how jobs claim them is documented on Service bays.
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 |
The shipped console pages are configured like this:
| Page | Work entity | Drop writes | Timeline drop also sets | Views |
|---|---|---|---|---|
| Support → Case Allocation | Case | Executive | First Response Due | Board, Gantt, Map (from the account's location) |
| Service → Allocation Console | Case (the page names no entity, so the console falls back to Case) | Executive | Nothing: no schedule field, so no Optimize day | Gantt (opens here), Board |
| Service → Settings → Service Order Dispatch | Service Order | Service Advisor, not Technician | No timeline | Board, Map (from the account's location) |
| CRM → Lead Allocation | Lead | Executive | Lead Due Date | Board, Gantt |
| Demo Allocation (no menu entry) | Product Demo | Executive | Appointment Date Time | Board, Gantt, Map |
| Allocation Console (visit plans; Field Sales menu entry switched off) | Visit Plan | Assigned To Resource | Plan Start Date and planned start time | Map (opens here), Gantt, Board |
None of the shipped pages sets closedStatuses, so each one hides only the default words, matched against the whole status value. These defaults hide cases that are Closed or Cancelled and demos that are Completed or Cancelled. They match no service order status and no lead status. So delivered and invoiced service orders, and converted or lost leads, stay on their consoles until you set closedStatuses on the page, for example Work Completed, Invoiced, Delivered.
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 → Design Studio → Apps → Mobile Apps, open the mobile app record and its Location Tracking tab:
| Setting | Default | Meaning |
|---|---|---|
| Enable location tracking | Off (the shipped xMatix One App has it on) | 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
The Executive on new leads, opportunities and appointments can be stamped from Partner Resource records (sequence, success criteria and rules) unless a Process Studio assignment rule writes it. Automatic owner assignment documents both, including the form fields and Operation values an administrator must add before partner-resource rules can match.
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.