> For the complete documentation index, see [llms.txt](https://changelog.visilean.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://changelog.visilean.com/quality/quality-changelog/release-1.0-2026/the-quality-module-checklists-from-build-to-sign-off.md).

# The Quality Module: Checklists from Build to Sign-off

A quality checklist passes through several hands before it counts. Someone writes it, someone fills it in on site, and one or more people sign it off. When the form, the evidence and the sign-off route live in different places, inspections stall between steps, rejections arrive without a reason, and nobody can say for certain which version of a question a past response was answered against. The Quality Module brings the whole cycle into VisiLean: build a checklist, assign it, fill it in, and send the response through as many approval stages as your process needs.

#### Why This Matters

Inspection records are evidence. They need to show what was asked, what was answered, what was attached to prove it, and who approved it. If a checklist is edited mid-project and that edit rewrites earlier records, the trail is broken. If an approver rejects a response without saying why, the rework becomes guesswork. And if sign-off is tied to named individuals, every change in site staff means reconfiguring every checklist. The Quality Module keeps each of these under control, so the record you hand over at the end of the job matches what actually happened on site.

#### What's New?

* **Checklists built in one place.** Build a checklist from pages, questions and approval stages, so the form and its sign-off route are set up together.
* **Versioning that protects past records.** Every edit creates a new version. Responses already submitted keep the version they were filled on, so changing a question later doesn't alter past records.
* **Lifecycle control.** Edit, deactivate or delete checklists as your inspection process changes over the life of the project.
* **Drafts for multi-visit inspections.** Save a part-finished checklist as a draft and come back to it later when an inspection can't be completed in one visit.
* **Evidence on every answer.** Attach photos and files to individual answers, and open any submitted response to see exactly what was answered.
* **Multi-stage approvals.** Each response moves through a configured chain of approval stages. Approvers can reject with a note explaining what needs fixing, and closed responses can be reopened and sent back for rework.
* **Groups and tags.** Assign a named group of people to an approval stage instead of naming individuals, and use tags to organise and find checklists.
* **Dashboard and admin listing.** The dashboard shows counts of pending, approved, rejected and overdue work, while an admin listing shows every checklist and response in one view.

#### How It Helps: Three Example Use Case Scenarios

A Quality Manager sets up a pre-pour inspection checklist with its questions split across pages and two approval stages: a site supervisor group, then a QA group. When a supervisor leaves the project, the Quality Manager updates the group once rather than editing every checklist that uses it.

A Site Engineer starts the inspection in the morning, saves it as a draft when the formwork isn't ready, and finishes it in the afternoon, attaching photos to the answers that need evidence. The approver spots a missing cover measurement, rejects the response with a note saying exactly what's needed, and the engineer fixes and resubmits it.

A Project Manager opens the dashboard before the weekly quality meeting, sees the overdue count, and works through the outstanding responses with the team. Because each response keeps the checklist version it was filled on, the records stay accurate even after the checklist is revised mid-project.

{% hint style="info" %}

#### Key Considerations & Caution Points

**Edits create new versions:** changing a checklist doesn't alter responses that have already been submitted. They keep the version they were filled on.

**Assign groups, not individuals:** assigning a group to an approval stage means a change in site staff is handled by updating one group.

**Rejections and reopening:** a rejected response carries the approver's note, and a closed response can be reopened to send it back for rework.
{% endhint %}