Creating and dispatching a job
A job is the unit of field work — created, scheduled, assigned, and completed.
When to use
Use this whenever field work has to be planned: a customer request, a ticket or service order from Service Management, a maintenance plan, or an internal job on a company asset.
Before you start
- Permissions:
field_service:readto see/field-service/jobs,field_service:writeto create,field_service:dispatchto schedule and assign,field_service:executefor the technician who runs the job. - Toggles (Settings):
service.require_checklist_completion,service.customer_signature_required,service.completion_photo_required,service.require_time_log_on_completion(all default off) add checks before a job can be closed;service.invoice_on_acceptance(default off, on for new companies) delays the invoice until the customer accepts. - Job types and templates decide the checklist and parts plan — see Job types & templates.
Create the job
Go to Field Service → Jobs (/field-service/jobs) and click New Job. Set the customer, location, required service, and priority.
Schedule it
Open Field Service → Schedule (/field-service/schedule) and place the job on the board for a date and time slot.
Assign a technician or team
Assign to an individual technician or a team based on skills, availability, and location.
Track to completion
The technician updates status through to completion; the job moves through the acceptance lifecycle before it can be billed.
Create from a ticket or service order
From a Service Management ticket or service order use the dispatch action; the job is created with a link back, and a second dispatch of the same ticket is refused. The ticket status follows the job.
Close the job
To finish, the technician enters a completion code (completed, partial, unable, no access or parts needed) and, unless the work was fully completed, a failure code. Checklist, photo, signature and time-log checks apply when their toggles are on.
Accept, dispute or void
If customer signature or invoice-on-acceptance is on, completion moves the job to “pending acceptance”. The customer accepts (invoice is then issued) or disputes it.

Statuses
| Status | Meaning | Who moves it |
|---|---|---|
| Open | Created, not yet assigned. | Coordinator (field_service:write). |
| Assigned | A technician or team is set. | Dispatcher (field_service:dispatch). |
| In progress | Work started on site. | Technician (field_service:execute). |
| On hold | Paused; still counted as open for SLA and dispatch. | Technician or dispatcher. |
| Pending acceptance | Technical work done, waiting for the customer. | Technician, via closing the job. |
| Completed | Technical close when no acceptance is required. | Technician. |
| Accepted | Customer signed off; invoice can follow. | Customer / coordinator. |
| Disputed | Customer rejected the work; goes back for rework. | Customer / coordinator. |
| Voided / Cancelled | Job dropped. Voiding is blocked while an invoice exists. | Coordinator. |
Tips & common mistakes
- Pick the right job purpose: an internal job (maintenance of your own asset) is never invoiced and its cost goes to a cost center; a customer job needs someone to pay.
- A job already linked to a service order is billed from the order, so it does not generate its own invoice.
- Void an invoice before voiding the job it came from.
- Reassigning someone outside the data scope returns “not found” — check the job’s scope or ask an administrator for per-job permission.
- Mixed completion codes (“partial”, “parts needed”) keep the work visible; do not close a job as completed just to clear the queue.