Build and Edit Checklists in the Master Matrix

Checklists V2 uses a matrix: task categories run down the left and units run across the top. This makes it easy to keep common standards while allowing unit-specific instructions.

What you will accomplish

By the end of this guide, you will be able to complete a checklist configuration from the correct CleanOver screen, understand the important checks before saving, and verify that the result is visible to the people who use it next.

Before you begin

• Decide whether the change belongs to Clean, Audit, or Maintenance.
• Write the expected result in language a field worker can understand.
• Sign in to the Admin workspace and confirm you are in the correct business context.
• Use real operational dates and the property’s local timezone when the workflow includes time.

Step 1: Choose the checklist type

Open Checklists V2 and select Clean, Audit, or Maintenance. Each tab is a separate matrix, so verify the tab before editing.

Expected result: The correct matrix is active.

Step 2: Find the task category

Search or scroll to the relevant category. Expand it to see individual tasks and their unit-specific cells.

Expected result: The target task row is visible.

Step 3: Choose the unit column

Locate the unit across the top. Use shortened unit names or horizontal scrolling when the matrix is wide.

Expected result: The intended task and unit intersect in one cell.

Step 4: Edit the task instruction

Open the cell and write a clear action, expected result, and evidence requirement. Keep one task focused on one observable outcome.

Expected result: The instruction is specific and testable.

Step 5: Set required behavior

Choose the answer type and whether the item is required. Use required status only when the job should truly be blocked without the answer.

Expected result: The completion rule matches operational importance.

Step 6: Apply changes carefully

Use bulk or copy actions only when the same wording is valid for every selected unit. Review the selected columns before confirming.

Expected result: No unrelated unit receives the change.

Step 7: Save and test on a job

Save the matrix, then open a matching pending job and confirm the checklist appears correctly.

Expected result: The field-facing job shows the new instruction and answer type.

Step 8: Communicate major changes

Tell affected staff when required evidence, process order, or safety instructions change.

Expected result: Workers understand the new requirement before their next job.

How to confirm the workflow is complete

• Refresh the destination list or calendar and confirm the saved record appears only once.
• Check the unit, date, status, owner or assignee, and any linked record before leaving the page.
• Open the next downstream view mentioned in the guide and confirm it shows the same information.
• Record an internal note when the action corrects historical data or changes another person’s responsibility.

Common issues and what to do

The expected record is missing

Clear old filters, check the date and business context, then search by the most specific identifier available. If the data comes from a connected provider, check connection and mapping status before recreating it manually.

A button is disabled

Look for a required field, incomplete checklist item, missing permission, locked lifecycle status, or unresolved linked task. Complete the highlighted requirement instead of trying to bypass it.

The page shows different information after refresh

Another user or integration may have updated the record. Compare timestamps and the source system, then apply the correction in the system that owns the data.

You are unsure whether to continue

Stop before cancelling, overwriting, revoking, or issuing a financial document. Ask the workflow owner to confirm the intended outcome and add that decision to the internal record.

Best practices

• Use clear names that make sense to a new team member without extra context.
• Prefer the smallest safe scope for bulk actions, filters, permissions, and date ranges.
• Keep guest-facing communication separate from internal diagnostic notes.
• Verify a high-risk change in a second view before considering it finished.
• Update the source configuration when the same correction is needed repeatedly.