Composer in 10 minutes: turning an inspection spreadsheet into a real workflow

The average safety team has somewhere between 20 and 200 inspection forms spread across SharePoint, Google Drive, and printed binders. Migrating them all at once is a dead-end. Migrating the three most-used forms in a Friday afternoon is not.

1. Open Composer → New module → Inspection template. Name it after the existing spreadsheet (Forklift Pre-Op, Hot Work Area Sweep, etc.).
2. Paste the column headers. Composer suggests field-block types: short text, select, yes/no, number, photo, signature.
3. Add a Location block — tree-picker with GPS toggle. This is the single biggest reason adoption spikes.
4. Wire the workflow: draft → submitted → reviewed → closed. Add a Guard that requires photo on any "fail" answer.
5. Publish to a location set. Assign by role, schedule by cron, and expose on the mobile home screen.

The reason most inspection programs stall at a shared drive is that the form is not the program — the workflow around the form is. A spreadsheet is a list of questions; a Composer inspection is a list of questions wired to a state machine, a schedule, an owner, a scoring rule, and an escalation. The ten minutes is the time to build the form; the work that makes it a program is the half-hour after, configuring the workflow and the schedule so the form actually fires on the floor.

The field-block palette is what makes a Composer inspection expressive without code. The block types a safety inspection actually uses are short text, long text, single select, multi-select, yes/no, number, date, photo, signature, location, user, and a repeating group for the line-item checklist (one block that renders as many rows as the inspector needs). The typed blocks matter because they make the downstream logic possible — a guard can branch on a yes/no, a computed field can sum a set of number blocks, and a report can group by a select. A spreadsheet with everything as free text gives you none of that.

• Yes/no with a fail guard — a "no" on a safety-critical question (gas test complete, harness inspected, isolation verified) can require a photo and block submission until it is attached. This is the control that turns a checklist into a permit.
• Photo with annotation — a fail answer that requires a photo captures the evidence at the moment the finding is made, not reconstructed later. The photo is timestamped and geotagged by the device.
• Location with GPS toggle — a tree-picker for the site hierarchy with a GPS pin for the exact point. The location feeds the report layer and the CAPA routing automatically.
• Signature — a competent-person sign-off captured on the device, which is what a permit-to-work or a pre-use inspection needs to be auditable.
• Repeating group — the line-item checklist that varies in length (inspect 3 fittings or 30) without a separate form per count.

Scoring and pass/fail is where an inspection becomes a decision rather than a record. A Composer inspection can carry a computed score — the sum of weighted answers, or the count of critical fails — and a pass/fail rule that branches the workflow. A failed critical item can route the record to a supervisor review, auto-spawn a CAPA with the finding pre-populated, or refuse to close until the finding is corrected. The score is not for its own sake; it is the trigger that decides whether the inspection closes clean or opens a corrective action.

Scheduling is what makes the inspection happen. A Composer module assigned by role and scheduled by cron fires on the cadence the program defines — a forklift pre-op at the start of every shift, a fire extinguisher walk monthly, a stormwater outfall inspection quarterly. The schedule creates the assignment, the assignment appears on the mobile home screen of the person in that role at that location, and a missed inspection escalates after a configurable grace period. The schedule is the difference between a form that exists and a form that gets filled in.

Offline capture is the requirement that decides whether field adoption holds. A forklift pre-op happens in a yard with no Wi-Fi, and a confined-space entry happens in a tank with no signal. The mobile client has to let the inspector open the form, fill it, capture photos and a signature, and submit — with the record queued and synced when the device reconnects. An inspection app that requires a live connection will be abandoned the first time the yard drops signal, and the inspector will revert to the clipboard.

The publish-and-version model is what makes the module safe to change. When a regulation changes or a finding pattern shows a gap, the safety lead edits the template and publishes a new version; in-flight inspections continue on the version they started on, and new inspections pick up the new version. The version history is the audit trail for the form itself — an inspector can be asked which version of the inspection they ran on a given date, and the platform answers without a rebuild.

The report layer is where the inspection data becomes a program view. The platform aggregates by location, by inspector, by failure type, and by time — the pass rate per site, the top failing questions across the fleet, the inspector whose fail rate is an outlier, and the trend that shows a site drifting. The same data feeds the leading-indicator dashboard: inspection closure time is a leading indicator because the report layer can compute it, not because someone cleans a spreadsheet.

The last connection is the one that makes inspections part of the safety program rather than a side activity. A failed inspection that auto-spawns a CAPA, with the finding linked and the SLA started, is a closed loop; a failed inspection that sits in a report until someone reads it is an open one. The Composer pattern is to wire the guard at the field, the score at the form, the schedule at the module, and the CAPA at the fail — so the inspection does not just record a problem, it starts the work that fixes it. For the related concepts, see the Composer tour and the inspections and permit-to-work material in the product guides.

The rollout is where a good module loses to a bad launch. The pattern that holds is a two-week pilot at one site with one crew, a weekly review of the first ten inspections filed, and a second two-week window at a second site before the fleet-wide publish. The first ten inspections are the calibration: the question that every inspector answers the same way is the question that does not need to be asked, and the question that every inspector answers differently is the question that needs a clearer definition or a worked example in the field help. A module pushed to the fleet on day one, without the pilot, collects a year of inconsistent data before anyone notices.

• Making every field required — an inspection where everything is mandatory is an inspection where the inspector speeds through the last half. Require only what the workflow or the report actually needs; leave the rest optional and the data stays honest.
• No fail guard on the safety-critical questions — a checklist where a critical "no" can be submitted without a photo or a comment is a checklist that records the failure and loses the evidence. The guard is the cheap part of the module and the part most often skipped.
• Scheduling without escalation — a daily inspection that is missed and never escalated is a daily inspection that stops being daily. Set the grace period and the escalation owner when you set the schedule, not after the first miss.
• Pilot by email — a module launched with a memo and no floor support is a module that reverts to the clipboard in a week. Walk the first shift with the inspectors; the questions they ask in the first hour are the ones the field help should answer.

The inspection data closes the loop with the audit evidence pack. An ISO 45001 or OSHA audit that asks for the inspection program produces, on a real platform, a report of every inspection in the period, every finding, every closure, and every CAPA spawned — assembled in the time it takes to filter, not in the weeks it takes to chase a shared drive. The module that started as a ten-minute Composer build ends as a line in the audit evidence, and the line is backed by the records, the photos, and the signatures, all on the same tenant as the rest of the safety program. For the auditor, that is the difference between a program that claims to inspect and a program that can show it inspected — and the second is the one that earns the certificate.