Lesson 4 — The three roles

Real operations applications have multiple kinds of users. A field service business doesn’t just have technicians; it also has dispatchers who decide where the technicians go and managers who decide how the business is performing. These users don’t share a screen — each has different needs, different responsibilities, and different access to data.

This tutorial builds the application for three distinct roles. Each role is a real perspective on the same underlying data, with different defaults, different navigation, and different scope. Understanding the roles up front matters because they shape decisions in almost every chapter — from the seed data we generate to the queries we write to the chrome on the page.

Field officer

A technician working in the field. Their interest is narrow and immediate: the job they’re on right now, the next job they’re being sent to, recently completed work, and a small amount of context about where they’re going.

Field officers see only their own data. The jobs page shows their jobs. The map shows their next destination. Reports aren’t relevant — managers run reports. Most of the powerful operations features are hidden because they aren’t useful at the field officer’s scale.

What a field officer needs from the application is right-now information. “Where am I going next? What’s the address? Who’s the customer? What’s the issue I’m being sent for?” Not aggregations, not historical trends, not regional summaries. Personal, contextual, immediate.

The field officer’s view appears throughout the tutorial as a constraint check — “what does the dispatcher do, and how does the field officer’s view differ?” Many features that make sense for a dispatcher’s roster don’t make sense for an individual technician’s day, and vice versa. The contrast is instructive.

Dispatcher

A dispatcher is responsible for assigning technicians to jobs across one or more service regions. They live in the application all day. They pick up new job requests, decide which technician to send, update statuses as the day unfolds, and intervene when things go wrong (a job overruns, a vehicle breaks down, a customer cancels).

Dispatchers see jobs and technicians scoped to their service regions. A dispatcher in Brisbane sees Queensland jobs; a dispatcher in Melbourne sees Victorian jobs; the system prevents them from accidentally interfering with each other’s work.

The dispatcher’s primary tool is the map. They look at the map to see where things are happening, where technicians are positioned, where the gaps in coverage are. They look at lists of jobs to prioritise their decisions. They use the drawing tool to mark ad-hoc service zones when patterns emerge (“we need extra coverage around the Caulfield exhibition this week”).

Building good dispatcher tools is the heart of this tutorial. Most of the interactive features we build — sortable filterable tables, choropleth views, click-to-drilldown, drawn polygons, real-time position tracking — are dispatcher-facing. If you imagine yourself as the user while you build, the dispatcher is the right user to imagine for most chapters.

Manager

A regional or national manager whose interest is operational performance, not individual jobs. Managers want to know how the business is doing — are response times within SLAs? Are there regions where job density is overwhelming our coverage? Which service categories are growing? Where should we expand?

Managers see everything, but they don’t operate at the job-by-job level. They look at aggregates. The manager’s home page is a dashboard with summary metrics, a national map showing job density as a choropleth, response-time aggregations per service area, and the ability to drill into specifics when something looks anomalous.

The manager’s view is where the scale-related features matter most — vector tiles serving half a million records, choropleth binning that picks the right colour scale, fast aggregations that don’t make the dashboard wait. Module 7 (Working at scale) is essentially the manager’s module.

How the roles compose with the application

Three things change between roles in the running application:

Navigation. A field officer’s sidebar shows Dashboard and Jobs. A dispatcher’s sidebar adds Technicians and Service Areas. A manager’s sidebar adds Reports. The same Components::Sidebar component, different items rendered.

Data scope. A field officer querying jobs sees only their own. A dispatcher sees their region’s. A manager sees everything. This is implemented as Job.visible_to(current_user) — a scope that reads the user’s role and their region assignment(s) and filters accordingly. The chassis ships a stub; we flesh it out as the tutorial progresses.

Default landing page. A field officer signs in and lands on their next job. A dispatcher lands on the map of their region. A manager lands on the national dashboard. The HomeController performs a role-aware redirect.

These three changes — navigation, scope, default — are most of what role-aware UI means in practice. There’s also access control (a field officer shouldn’t be able to call a dispatch endpoint), but that’s a Module 11 / Appendix concern. For most of the tutorial, the role mechanics are implicit.

The development role switcher

Working through this tutorial, you’ll need to see the application from each role’s perspective. Logging out and signing in as different users dozens of times per chapter would be tedious.

The chassis includes a development-only role switcher in the top bar. Click the dropdown labelled “DEV”, choose a role, and you’re signed in as the corresponding seeded user. The seed data ships with three users —manager@vera.test, dispatcher@vera.test, and field_officer@vera.test — each with the matching role.

The role switcher is gated by Rails.env.development? and is genuinely invisible in production. The mechanism uses real authentication: clicking “Manager” signs you out and signs you back in as the manager seed user. So everything else in the application — Current.user, current_user.role, scoped queries — works exactly as it would in production. There’s no “impersonation” magic that could leak.

When a chapter introduces a feature, you’ll often see it from the dispatcher’s view first (because that’s our primary user) and then either explicitly or by implication, from the manager’s view. Use the role switcher to see for yourself.

Roles aren’t the focus, but they shape the structure

This tutorial isn’t about authorisation patterns. We don’t go deep on Pundit or CanCanCan; the chassis ships a thin policy layer that handles the basics, and Appendix 1 covers the role-based access control patterns in more depth for readers who want them.

But the existence of three roles influences every chapter. When we build a feature, the question “which role is this for?” almost always has a clear answer, and that answer shapes the design. A choropleth on the home page is implicitly a manager’s feature. A “my next job” view is implicitly a field officer’s feature. Knowing this up front means the tutorial reads more coherently.

It also means the application you finish with feels like a real product rather than a demo. Real products have real users with real roles. Toy applications don’t.

---

That’s Module 1. The next module starts the actual build — installing PostGIS, configuring the Rails 8 project, dropping in the chassis, and rendering an empty map of Australia. See you there.