Service has deliberately little configuration of its own: one module switch, the service-bay register, and a set of masters — item types, service contract definitions, checklist templates, picklists — that the module reads rather than owns. This page is the administrator's map of all of it, with links to where each master is documented.
The module switch
The Service module is governed by the platform's module settings (Setup → Feature Hub): a master Enable Service switch, on by default, which when overridden off makes the module unavailable to every user in the tenant — including users holding licenses and seat assignments. That switch is the Service module's only module-level setting. Individual access on top of it is the usual pair: licensing and security profiles, which decide who sees the Service app, its entities and its server actions.
Service bays
Service bays are the workshop's physical work positions, maintained as Service Bay records. The shipped configuration places the entity in the Service Settings App rather than in the Service app; administrators can also add it to any other app's navigation. Access follows the usual entity permissions: a user needs an app that lists the entity and the Service Bay entity on their security profile to see or edit bays.
- 1
Name is system-assigned on save (a dated sequence) and is what allocation refusals quote.
- 2
Branch: booking narrows candidate bays to the appointment's branch; a bay with no branch serves any.
- 3
Service Bay Type is what an appointment requirement matches on — extend the picklist for new kinds of position.
- 4
Allow Inventory marks a bay that can also hold stock (bin or pallet).
- 5
New opens the bay form; Edit switches the list to inline editing.
Use All Service Bays as the register of configured workshop positions (Service Settings App → Service Bays, or /ServiceBay). The list shows each bay's system-assigned name, branch, type, Allow Inventory flag and audit ownership; filter by branch before adding another position so the same physical bay is not created twice. The list proves the record exists, not that its capacity and allocation settings are what scheduling expects — check those on the saved record.
- 1
Service Bay Type is what an appointment requirement matches on — a wash slot books a Washing Bay, a health check a VHC Bay.
- 2
Branch locates the bay; booking narrows candidates to the appointment's branch, and a bay with no branch serves any.
- 3
Is Active (default on) keeps the bay in allocation pickers; switch it off to retire the bay without losing its booking history.
- 4
Vehicle Capacity and Labour Capacity are separate ceilings — cars inside versus technicians working — both default to 1 and refuse values below 1.
- 5
Allocation Mode (Vehicle, Labour or Both) decides whether the bay is claimed from the service order, from a time-sheet line, or either.
- 6
Auto Release After and Turnaround are minutes; blank means never auto-release and the mode's default turnaround (15 vehicle, 5 labour).
The create form asks for Service Bay Type, Branch and Is Active, then a Capacity & Allocation section — Vehicle Capacity, Labour Capacity, Turnaround, Auto Release After, Allocation Mode and Allow Inventory; the bay's name is assigned by the document numbering setting on save. Branch locates the physical position, the type lets booking requirements match the kind of work, and Allow Inventory marks a bay that may also act as a stock-holding position. Older tenant layouts show only Branch, Service Bay Type and Allow Inventory; the scheduling fields below are on the entity regardless and can be added to the form through the data model tools.
| Field | Meaning |
|---|---|
| Name | System-assigned reference (for example a dated sequence), used in allocation messages |
| Service bay type | What kind of position it is — Van, Plant, Workshop, Bin, Pallet, Washing Bay, Regular Bay, VHC Bay; a picklist you can extend |
| Branch | The branch the bay belongs to |
| Allow inventory | Marks a bay that can also act as a stock-holding position |
| External ID | A stable identifier for mapping the bay to outside systems |
Where a scheduling field is blank, the server applies the default shown when the bay is saved, so a bay created through the form, an import or the API behaves the same way.
| Scheduling field | Meaning and default |
|---|---|
| Is Active | Retires a bay from allocation pickers and booking candidates without discarding its booking history; defaults to on |
| Allocation Mode | Where the bay may be claimed: Vehicle for a whole job (from the service order), Labour for a time-sheet operation, or Both; defaults to Vehicle, and any other value is refused |
| Vehicle Capacity | Maximum distinct vehicles the bay can hold at once; defaults to 1, and a value below 1 is refused (Vehicle capacity must be at least 1) |
| Labour Capacity | Maximum simultaneous technician-operation claims; defaults to 1, and a value below 1 is refused |
| Auto Release After Minutes | Release an overdue claim automatically this many minutes past its promised window; blank or zero (the default) never releases |
| Occupancy Stretch Percent | How much longer than its booked time a job holds this bay, as a percentage (160 = a 2.5-hour job occupies it for 4 hours); blank uses the mode default |
| Turnaround Minutes | Minutes added to every claim for getting the vehicle in and out; blank uses the mode default |
- 1
The system-assigned name is what allocation refusals quote, for example 'Bay SB-… is full for this window'.
- 2
Header statistics repeat Branch, Service Bay Type and Allow Inventory.
- 3
Related lists records tied to the bay; Details (open) holds the configuration.
- 4
Is Active on: the bay is offered to allocation pickers and booking candidates.
- 5
Vehicle Capacity 1 / Labour Capacity 1: one car and one technician at a time; raise Labour Capacity to admit a helper on the same car.
- 6
Allocation Mode Vehicle: this bay is claimed from the service order for the whole job, not from time-sheet operations.
The saved bay opens on Related and Details; Details repeats Key Information (type, branch, active) and the Capacity & Allocation section, which is where to confirm what scheduling will actually use. Edit and Delete are the header actions.
Bays matter to appointment booking and workshop allocation. Saving a bay creates or refreshes its bookable-resource wrapper of kind Facility in the same save — administrators never create that wrapper by hand — and the wrapper mirrors the bay's branch, active state and labour capacity. A booking requirement can demand a bay type, so a wash slot books against washing bays and a health-check slot against VHC bays. Vehicle and labour capacities stay separate deliberately: a bay of 1 vehicle / 2 labour admits a lead and a helper on the same car but refuses a second technician arriving with a different car. When a bay cannot take a job the allocation is refused with a message naming the bay and, depending on the case, the next slot that fits, the too-short free window, the occupant overrunning it, or its vehicle and in-progress counts for that window (Bay … is full for this window (1/1 vehicles, 2/2 in progress)).
Masters the module reads
| Master | What it drives in Service | Where it is managed |
|---|---|---|
| Item type | The fork in service order behaviour: Part lines flow through fulfilment, allocation, picking and inventory posting; Work Item lines flow onto time sheets; Service Contract items create entitlements when invoiced | The item record |
| Service contract definitions (Item Service Contract) | Validity, usage windows, grace, covered scope, enforcement switches and posting treatment for contract-covered work | On the contract item — see asset service contracts |
| Checklist templates | The checks populated onto service orders (template type Service Order), and the recommendation rules that turn findings into proposed work | Field Sales Setup app — see checklists |
| Price lists, discount groups, tax groups | Line pricing, cascading discounts and header taxes on service orders and estimates | Shared with Sales — see pricing, discounts and taxes |
| Service type picklist | The order's classification — Paid Repairs, Warranty Repairs, Refurbishment, Campaign Repair — extendable like any picklist | The entity's picklist values |
| Work pause reason picklist | The reasons a technician can give when pausing a time-sheet line | The time sheet entities' picklist values |
| Resources | Technicians and service advisors validated on orders, and the workers time sheet lines attribute labour to | The resource register |
Picklists (service type, bay type, recommendation condition and the rest) and the entities' fields, views and layouts are all customisable through the ordinary data model tools — Service entities are standard platform entities.
Common questions
Users can't see the Service app — what do I check?
In order: the module's Enable Service switch (off hides it from everyone), the user's license, and the security profile's app and entity permissions. The general diagnosis path is the user-can't-see-X guide.
Why is a service order behaving like a parts order with no labour flow?
Check the items on its lines: the item type is the fork. A labour item created as an ordinary inventory item (rather than a Work Item) goes down the parts path — fulfilment and allocation — and never appears on a time sheet.
Where is dispatch configured?
Not here. Crew scheduling, the dispatch console and skills-based routing are Field Service concerns. What Service configures is the workshop side: bays for appointment booking, and the masters above.