A confirmed appointment says when someone will arrive, but it does not describe the work the business now owes. A Service Request records what the customer asked for, and a conversation records how the team learned it. The Job is the operational object carried into dispatch and execution. Lavenity creates that Job automatically when an appointment is confirmed, closing the gap between a booked time and accountable field work.
A booking time and a work obligation are different records
Appointment confirmation and Job creation happen in the same database transaction. There is no interval in which the customer has a confirmed visit but the dispatch queue has no work order because a background worker restarted. A unique relationship between appointment and Job guarantees one work order per booking. Repeated or concurrent confirmation returns the same records rather than creating two obligations for one visit.
Each Job receives a structured brief snapshot at booking time. It includes the service, customer contact, address, access notes, asset details, urgency, request summary, and qualification answers. The snapshot matters because the accepted instructions should not change silently if someone later edits the original request. Operators can add explicit Job notes when the field team needs a correction or update.
One transaction and one unique index close the reliability gap
The Job has a lifecycle designed for both a dispatch team and a one-technician business: created, dispatched, in progress, completed, or cancelled. Dispatch is optional, so an owner-operator can move directly from created to in progress or completed. Completed and cancelled are terminal states; reopening finished work would blur reporting and any future invoice or connector history, so follow-up work becomes a new visit instead.
Cancellation respects what has already happened. Cancelling an appointment automatically cancels a Job that is still created or dispatched because nobody should carry stale work for a visit that is no longer taking place. A Job already in progress or completed is not erased by the calendar change. At that point time or work may already have been spent, and an operator must decide the commercial outcome.
The technician brief freezes the accepted operational context
The Jobs workspace turns the model into daily operations. Teams can filter work by status or resource, open a detail view, read the technician brief, add notes, follow the linked request and appointment, and move the work through its valid next states. Stable JOB numbers make work easy to reference outside the screen, while tenant-scoped APIs and version checks protect cross-workspace access and stale edits.
A deliberate lifecycle makes dispatch and reporting trustworthy
Jobs also create the far end of the Front Office funnel. The business can now measure more than conversations answered or requests qualified: it can connect an inbound message to a booked appointment and completed work. Future quote, invoice, ERP, and field-service integrations can subscribe to durable Job events without redefining the customer conversation, scheduling record, or work-order lifecycle that already exists.
Verify the handoff from booking to field work
Confirm a qualified request with a resource and appointment, then open Jobs. The new Job should have one stable number, link to the same request and appointment, and contain the service, contact, address, access information, asset, urgency, summary, and qualification answers the booking relied on.
Confirm the appointment again and from a competing session. Both paths should resolve to the same Job. Edit the original request after booking and verify that the technician brief does not change silently; add an explicit Job note for any correction the field team must see.
Move one Job through dispatch and in progress, then cancel its appointment. Compare it with a second Job whose visit is cancelled before work starts. The untouched Job should be cancelled automatically, while work already under way should remain for an operator to resolve. Those two outcomes prove the lifecycle reflects reality rather than merely mirroring the calendar.
Frequently asked question
Why does Lavenity create a Job as soon as an appointment is confirmed?
Because a confirmed appointment is a promise that the business now owes work. Creating the Job in the same transaction prevents a restart or queue delay from leaving a valid booking without a work order. A unique appointment-to-Job relationship also makes repeated and concurrent confirmation idempotent: one appointment produces exactly one operational obligation.