The problem: a printed list and a group chat
Dispatchers describe it the same way on every discovery call — a composite, not a customer quote: the technicians work from a printed list and a group chat, photos live on their phones, signatures live on paper that lives in the van, and when a customer asks what happened on Tuesday, somebody calls the tech.
The dispatcher wants a queue that is true at 8 a.m. and still true at 4 p.m. The technician wants one screen per stop that works in a basement with no signal. The customer wants a report the same day. None of that needs a custom platform. It needs objects, forms, a workflow, and a phone.
What gets built: four tables, two workflows, one PDF
Field-service and inspection apps are one of the shapes this platform has shipped for years: work-item queues, location tracking, offline mode, photo and signature capture. Your agent assembles them from governed primitives through named operations.
- Objects:
fsv_site,fsv_work_order,fsv_visit,fsv_finding— real tables, with a lookup from work order to site and from visit to work order. - Forms: the visit form takes location, photos and a customer signature; the finding form takes a severity and a photo. Required and read-only rules where the process needs them.
- Workflows: assignment pushes a notification to the technician; completion generates a PDF visit report and emails it to the site contact.
- Grids: today’s queue by technician is an object view joining site and work order, filtered to the signed-in user; open findings by severity for the dispatcher.
- Screens and groups: a generated screenflow per object; drawer entries and actions gated so technicians see their queue and dispatchers see everything.
Starter prompt
Build a solution called Field Service for a company that sends technicians to customer sites.
Objects: Site (name, address, contact name, contact email); Work Order (site, description, priority as multiple choice, assigned technician, status); Visit (work order, technician, arrived at, location, photos, notes, customer signature); Finding (visit, category, severity, photo, note).
Create a Dispatchers group that sees everything and a Technicians group that sees only work orders assigned to them.
Generate the screens so a technician can work today's queue on a phone, capture photos and a signature on site, and mark the visit complete.
Add a grid of today's work orders by technician and a grid of open findings by severity.
Add a workflow that generates a PDF visit report when a visit is marked complete and emails it to the site contact.
Preview the diff before you commit.
Ship it: publish once, phones pick it up
The renderer is the same on the web and on the phone in the technician’s hand. Field-service apps built on it use offline mode, location tracking, and photo and signature capture today — we will show you the offline behavior in a demo rather than over-promise it on a page.
When the queue is right, publish-solution pushes Current to Testing and Production in one step, and the technicians’ phones pick up the new screens at the next sign-in. Who sees which stops is governed by groups. Every edit before that is staged in a transaction, previewed as an entity-level diff, and committed as one save — or rolled back.
Integrations used
PDF report generation and email are workflow activities, not add-ons. Push notifications reach the technician’s phone. When your back office needs to know a job closed, an ExternalService activity posts to Zapier, Make, n8n or any HTTP endpoint.
Workflows run as asynchronous activity chains with an activity log you can read. We do not claim exactly-once delivery or automatic retries — the record of what happened on a visit lives in the app, not in an email that may or may not land.
Related
- Blueprint: Field service inspection — the copyable primitives map and prompt.
- Closed in 24 Hours: Paper inspections replaced in 19 hours — an illustrative build, hour by hour.
- Next use case: Inspections and checklists — when the visit is a compliance record.
- Selling this into a prospect? See pre-sales solutions.
Your IT lead will ask who can publish this, who can see the data, and what the agent is allowed to touch. The answers are written for them: the IT brief · security and governance.