What the add-on plugs into - plans, roles, workflows, files, billing - and the two consequences to plan around.
Loading the guide...
Did this answer your question?
Help us make the guides more useful.
0 helpful · 0 not helpful
What the add-on plugs into - plans, roles, workflows, files, billing - and the two consequences to plan around.
Loading the guide...
Help us make the guides more useful.
0 helpful · 0 not helpful
Dispatch is an add-on rather than a fork. It fills the extension points your CRM ships empty, which is why it behaves like part of the product instead of something bolted alongside it. Practically, that means:
| It plugs into | What you get |
|---|---|
| Plans | A Dispatch toggle appears in your plan editor under Add-ons, so you can sell it as a tier instead of giving it to every client |
| Roles and permissions | Jobs, Dispatch Board and Technicians appear as ordinary permission modules in the role editor |
| Navigation | The Dispatch row appears in the sidebar, gated on the plan and the role |
| Workflows | Dispatch triggers and action nodes join the existing palette, and its ready-made workflows join your template gallery |
| Estimates and invoices | Field billing writes into the CRM's own records. There is no second ledger |
| Contacts | Service locations are built from your existing contacts, and jobs point at real contact records |
| Files | Job photos and documents are CRM files, counted in your storage and covered by the CRM's Files permission |
| Forms | Dispatch field types are available on public forms, so a form can capture a service address, gate code and preferred window straight onto a job |
| Public pages | The tracking, gallery and adjuster links are registered as public routes, each scoped by its own token |
| Scheduled tasks | Recurring visit generation, geocoding passes and retention cleanup run on the CRM's own scheduler |
| Offline | My Day registers with the CRM's service worker, which is what lets it survive a dead spot |
| Snapshots and purge | Dispatch data is included when a sub-account is snapshotted or purged, so it is never left behind |
| Deleting a user | Removing a CRM user cleans up their dispatch records rather than orphaning them |
Two consequences worth planning around:
Re-run the installer after any CRM update. A CRM update decides what to keep by comparing file fingerprints, and on an install it cannot classify, the extension files can be replaced with the empty originals. Dispatch then goes quiet with a green build and a clean setup check. Re-running the installer restores the wiring.
Technicians are real CRM users. Every technician on the roster has a login, because My Day, photo uploads and location consent all require one. If the plans you sell your clients meter by seat, a client's technicians count like any other user they add. The reverse is not true: adding a user does not put them on the roster.