Dispatch deck — Entity-relationship diagram

The data model after Module 5’s operational schema lands. This diagram is the canonical reference for how the dispatch deck’s entities relate; subsequent modules add behaviour but don’t change this shape.

Diagram

Reading the diagram

The dispatch deck has five core entities:

User is the unified account model — managers, dispatchers, and field officers are all User records distinguished by role. Two optional foreign keys pin role-specific data: depot_id is populated for dispatchers (their operational home), and service_area_id is populated for field officers (their patch). Managers have neither.

Depot is a regional dispatch hub. Each depot has one or more dispatchers (one per shift in reality; one in the seed) and oversees a set of service areas covering its operational region.

ServiceArea is an ABS Statistical Area Level 3 boundary, about 90 km² for inner-suburban examples, much larger for remote regions. Each SA3 belongs to a depot (which dispatcher team is responsible) and houses any number of field officers posted there.

Customer is the requester of work. Each customer has a location (their address geocoded to a point) and can have many jobs over time.

Job is the operational record — a piece of work to be done at a customer’s location. Each job belongs to a customer (who requested it), a service area (where the work is happening), and optionally to a field officer (who’s been assigned to do it). Job status tracks the lifecycle.

How relationships drive scope

The reason this shape matters: it determines what each role sees in the dispatch deck.

A dispatcher’s view is scoped to their depot’s service areas:

1
2
3
4

current_user.depot.service_areas
# => the SA3s the dispatcher coordinates
current_user.depot.service_areas.flat_map(&:jobs)
# => the jobs in their region

A field officer’s view is scoped to their service area:

1
2
3
4

current_user.service_area
# => their patch
current_user.service_area.jobs
# => jobs in their patch (recent / today's)

A manager’s view has no scope — they see everything.

These scopes drive the SerializeServiceAreas and SerializeJobs services, the role-aware home pages, and the spatial query lessons in Module 6.

What’s not in the model (yet)

A few things you might expect that are deliberately omitted:

• Technician positions (real-time location of field officers). Module 9’s territory; lives in a separate streaming pipeline, not the database.
• Customer-as-business — the model treats every customer as a single entity. Real operations distinguish residential vs commercial; the tutorial doesn’t.
• Notes, attachments, billing records. Out of scope.
• Shift / roster / availability tables. A real dispatch app tracks who’s working when; the tutorial assumes everyone is always on.

These keep the model focused on what’s needed to teach the spatial and operational patterns at the tutorial’s heart.