The problem: the checklist is a PDF, the audit is a dig
Compliance leads describe the same thing on discovery calls — a composite, not a customer quote. The checklist is a PDF. Inspectors print it, tick it, photograph it, and email the photo. When something fails, the corrective action is a reminder on someone’s phone. When the auditor asks who changed the result on line 14, the room goes quiet.
Compliance work has a shape: a packet of questions, a pass or a fail per line, evidence on the fails, somebody accountable for fixing them, and a record that cannot be quietly edited. The tools that get this right are heavy. The spreadsheet that gets it wrong is free.
What gets built: packets, pass-fail items, a log that stays
Checklist and compliance apps have run on this platform for years: multi-step form packets, stage-based workflows, activity logs and an audit trail. Your agent builds the packet one named operation at a time.
- Objects:
chk_asset,chk_inspection,chk_item,chk_corrective_action— real tables, with lookups from inspection to asset and from item to inspection. - Forms: the inspection is a multi-step packet with a section per area. Rules make the photo required when the result is fail. The inspector signs the last step.
- Workflows: stage-based — submitted, reviewed, closed. A failed item creates a corrective action and emails its owner; closing an inspection generates a PDF certificate.
- Audit trail: the change log is on for inspection and corrective action, so who changed what, and when, is a row you can read — through the app or through
get-instance-changelog. - Grids and groups: overdue inspections and open corrective actions by owner; inspectors submit, QA reviewers close, and the actions are gated server-side.
Starter prompt
Build a solution called Site Compliance for a team that inspects assets against a checklist every month.
Objects: Asset (name, location, owner email); Inspection (asset, inspector, date, status as multiple choice: draft / submitted / reviewed / closed, inspector signature); Item (inspection, area, question, result as pass / fail / n.a., photo, note); Corrective Action (inspection, description, owner, due date, evidence photo, resolved).
Make the inspection form a multi-step packet with one section per area, and make the photo required when an item's result is fail.
Turn on the change log for Inspection and Corrective Action.
Create an Inspectors group that can create and submit inspections and a QA Reviewers group that can review and close them.
Add a workflow that creates a Corrective Action and emails the asset owner whenever an item fails, and one that generates a PDF certificate when an inspection is closed.
Add grids for overdue inspections and open corrective actions by owner. Preview the diff before you commit.
Ship it: publish the packet, keep the record
Inspectors work the packet on a phone or a laptop — the renderer is the same on both. Photos and the signature are captured in the form. Reviewers see the queue of submitted inspections and close them from the same app.
publish-solution lands Current in Testing and Production in one step — a new question mid-quarter is a staged edit, not a migration. Every change to the checklist itself is previewed as an entity-level diff and committed as one save. The change log on existing records is separate from that, and it keeps running across every version of the packet.
Integrations used
PDF certificates and email are workflow activities. When a fail needs to open a ticket somewhere else, an ExternalService activity posts the record to Zapier, Make, n8n or any HTTP endpoint you name — asynchronously, with an activity log you can read, and no retry or delivery guarantee claimed.
Related
- Blueprint: Compliance checklist — the copyable primitives map and prompt.
- Closed in 24 Hours: Paper inspections replaced in 19 hours — an illustrative build with the same bones.
- Previous use case: Field service — the same packet, on a technician’s queue.
- Next use case: Workflow and approvals — when the corrective action needs a sign-off.
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.