Overview
Use a limited pilot to check a new inspection with the people who will perform and review it. Keep the test scope explicit so an unfinished form or trigger does not reach all operational Locations.
At a glance |
|
Who can do this | Super Users, Checklists › Modify, or authorized Checklist folder Editors. Creating a Schedule requires the appropriate Schedule access. |
Where | Checklists, Schedules and Results |
Works on | Backend (web), Mobile app |
Availability | All organizations |
💡 Why this matters: A complete pilot tests the inspection, its follow-up work and its report before the wider team depends on it.
Before you start
Agree a suitable test Location, Users and timing. If testing at an operational Location, coordinate the pilot so it does not replace required work or alter readiness unexpectedly. Decide in advance how pilot Results will be distinguished in reporting.
Walkthrough
1. Make an independent test Checklist
Create the new Checklist, or select an existing one and use Create Copy. Give the copy a recognizable pilot title. A copy is independent; edits to it do not update the original. Review copied triggers and references before anyone completes it.
2. Limit the pilot Schedule
Create a Schedule with only the pilot Checklist under What? and the agreed Location under Where?. Choose the actual pilot assignees and reviewers under Who?. Do not select a broad Location Group by habit.
3. Choose a controlled work window
Use a dated Specific slot when a single pilot window is appropriate. Review compliance and criticality settings deliberately, then save. Confirm the intended work appears for a representative User and that operational work remains available.
4. Review behavior and outputs
Complete the intended normal and exception paths. Check hidden pages, required evidence, trigger-created work and the resulting report. Use the review findings to edit the pilot, then repeat only the affected paths.
5. Plan the operational changeover
Review the Checklist’s Usages and the live Schedules that will change. Choose a changeover after active work is accounted for. Update reporting filters and Notification Rules that name a Checklist identity, and close out the pilot Schedule deliberately.
Check the outcome
There is no separate draft-and-publish stage in the Checklist editor: saving updates that Checklist immediately. Keep test content isolated through the chosen Checklist and Schedule scope. Historical Results stay associated with their original Checklist identities. See Checklist maintenance and Schedule stopping options.
Best practices
Include a representative performer and reviewer in the pilot.
Test real trigger consequences in a controlled scope.
Record the approved changeover date and Checklist identity.
Frequently asked questions
Can I copy a Checklist to test changes?
Yes. Create Copy makes an independent Checklist. It does not create a Schedule or transfer historical Results to the copy.
Why does test work appear twice?
Check whether both the pilot and operational Schedule target the same User, Checklist or Location, and inspect inherited timing. Do not assume the two entries are duplicate Results.
Will saving the pilot change the original Checklist?
No, when it is an independent copy. Saving edits does immediately change the copy wherever that copy is already scheduled.





