The Edit Checklist page is where existing checklists are modified and refined. Checklists may need editing to add new fields, adjust scoring, fix errors, or adapt to changing requirements. This page provides a live preview alongside the editing interface, allowing changes to be tested before they're deployed.
The page handles two distinct scenarios: minor edits to active checklists (which update automatically everywhere), and breaking changes that require deciding whether to update existing deployments or create a new version. Breaking changes are large modifications that affect the data being collected - adding or deleting fields, for example. This is also where conditional logic and scoring are configured, transforming basic question lists into intelligent forms that adapt to auditor responses and generate meaningful analytics.
Interface Layout
Go to Dashboard > Audit Checklists > Edit.
Left panel: Fields
Lists all fields in the checklist. Each field can be edited or deleted. Fields appear in the order they'll be shown to auditors during inspections.
Right panel: Live Preview
Shows how the checklist will appear to auditors on their mobile devices. Click Refresh Preview to update the preview with recent changes. The preview doesn't update automatically - it must be manually refreshed to reflect new or edited fields. Use this to test conditional logic, check question flow, and verify the checklist works as intended before deploying to live jobs.
Basic Editing
Edit title and description
Click below the checklist name to modify the checklist title or description. These changes don't affect data collection and update immediately across all deployments without triggering version control.
Edit field
Click Edit next to a field to open the field editor. Modify the question text, field type, answer options, scoring settings, or conditional rules. Minor changes (fixing typos, clarifying question text) update automatically. Major changes that alter data structure trigger version control.
Delete field
Click Delete next to a field to remove it from the checklist. This is a breaking change if the checklist is already deployed in active audit jobs, as it removes a data collection point that may already have historical data associated with it.
Advanced Features
Rules > Hidden by default
Makes a field invisible unless triggered by a conditional rule. Use this for fields that should only appear in specific circumstances. For example, a detailed cleaning protocol question that only shows if an auditor marks a space as "Failed Initial Inspection." Hidden fields keep checklists shorter and more focused by showing auditors only what's relevant to their current situation.
Rules > IF Rules
Creates conditional logic to show or hide fields based on answers to previous questions. Examples:
- IF answer to "Are toilets accessible?" is "No," THEN show "Describe accessibility barriers"
- IF answer to "Pest evidence found?" is "Yes," THEN show photo upload field and "Describe pest type"
Rules are processed in order from top to bottom. Multiple overlapping rules may produce unexpected results. For example, one rule showing a field while another hides it, with the last rule processed taking precedence. Test thoroughly in the preview window before publishing changes. Walk through different answer scenarios to ensure fields appear and disappear as intended.
Score > Access analytics
Opens scoring settings for the field. Determines how the field contributes to overall checklist scores and analytics. Can assign point values to different answer options, set weighting for the field's importance, or exclude the field from scoring entirely. Scoring enables comparison across venues, auditors, and time periods, turning qualitative assessments into quantifiable metrics.
Breaking Changes: Update or Version
When making breaking changes to live checklists (adding or deleting fields, changing field types that affect data structure), two options appear:
Update All Deployments
Replaces the existing checklist everywhere it's currently being used. All audit jobs, venues, and auditors using this checklist will immediately receive the updated version. This affects active audits and changes how data is collected going forward. What happens:
- Auditors see the new checklist structure next time they sync
- New data follows the new format
- Historical data from before the change remains in its original format
- Reports may show inconsistencies between old and new data structures
- Any removed fields become unavailable, though historical data from those fields is preserved
When to use this: The change needs to apply universally and immediately. For example, fixing a critical error in scoring logic, adding a mandatory compliance field required by new regulations, or removing a field that's no longer relevant to any deployment.
Save as New Version
Creates a new checklist while keeping the existing version active. The original checklist continues to run in all current deployments unchanged. The new version exists as a separate checklist that must be manually assigned to replace the old one where needed. What happens:
- Original checklist remains deployed in all existing audit jobs
- New version appears in the checklist library as a separate item
- To deploy the new version, go to Dashboard > Audit Jobs > Details > Venues (to replace for specific venues) or Dashboard > Audit Jobs > Details > Auditors (to replace for specific auditors)
- Both versions can run simultaneously in different jobs
- Historical data remains consistent within each version
When to use this: Changes should be tested before full rollout, when different audit jobs need different checklist versions running simultaneously, or you want to preserve the original checklist for comparison or archival purposes. For example, piloting a revised inspection protocol with one team before rolling out to everyone, or maintaining separate checklists for different client requirements.
Testing Before Publishing
Always test changes in the preview window before deploying to live audit jobs. Walk through the checklist as if completing an inspection:
- Answer questions in different ways to trigger conditional logic
- Verify hidden fields appear when they should
- Check that irrelevant fields stay hidden
- Confirm scoring calculates correctly
- Ensure the question flow makes sense to auditors
Testing catches issues like circular logic (Field A shows Field B, which shows Field C, which hides Field A), orphaned fields that never appear, or confusing question sequences that slow down auditors in the field.