First Class Modules

Checklists & Signoffs

Attaches reusable, versioned checklists to authorized records and lets each item require notes, documents, or photos before the completed run enters the existing Workflow signoff path.

Use Checklists & Signoffs when work must be performed step by step and accepted with reviewable evidence. A run can attach to a ticket, project, work order, or other universal record without copying that record or inventing another approval system.

What it does

Attaches reusable, versioned checklists to authorized records and lets each item require notes, documents, or photos before the completed run enters the existing Workflow signoff path.

Key capabilities

• Create reusable versioned templates with ordered required or optional items.
• Attach a template snapshot to any authorized universal record.
• Track up to 1,000 ordered run items with completion actor, time, note, and revision.
• Require one or more native File documents or photos as proof for selected items.
• Calculate bounded progress and refuse submission while required work or evidence is missing.
• Submit exactly one current run to the existing Workflow and Universal Inbox approval path.
• Support rejection, editing, proof replacement, resubmission, approval, and replayable history.
• Reject stale revisions and make duplicate completion, submission, and decision requests idempotent.

Common uses

• Work-order inspection and closeout proof.
• Project stage-gate and quality checklists.
• Support-ticket diagnostic or escalation checkoffs.
• Safety, compliance, onboarding, handoff, and document-review signoffs.

How it connects

Runs attach through universal Record relationships. Evidence remains a native File, decisions remain Workflow approval records, reviewer attention remains in Universal Inbox, and activity/audit records preserve the end-to-end chain.

Where applicable, its records use the universal RecordId conventions so they can participate in secured relationships, activity history, favorites, dynamic fields, notifications, Inbox attention, and global search without copying the source record.

Security and data boundary

Every list, detail, item update, evidence link/download, submission, and decision derives tenant, user, DataRole, Location, and source-record scope from server identity. Evidence links do not grant File access, and Workflow permissions—not checklist UI state—control signoff authority.

• The authenticated service derives the SaaS app, tenant account, user, DataRole, and location scope; browser identifiers are never authorization proof.
• The page editor composes React components with validated data bindings. Those bindings call typed runtime APIs, whose application services execute reviewed stored procedures.
• List, search, detail, relation, activity, favorite, and write operations reapply their required server-side permissions.

Add it to an app

1. Add module.checklists-signoffs to the source-record pages and menus where users perform or review work.
2. Create a versioned template with ordered items, required/optional state, proof type, and responsible role.
3. Grant source-record, checklist action, Workflow approval, File, DataRole, and Location permissions independently.
4. Attach a run to a representative ticket, project, work order, or custom record and complete it with required notes/documents/photos.
5. Test cross-tenant and cross-location denial, stale and duplicate requests, unauthorized file access, reject/edit/replace/resubmit/approve, failure recovery, and a 1,000-item boundary run before publishing.