Snagging

Snagging is where outstanding defects are tracked at the end of a job. The tab isn’t there for most of a project’s life: it appears when an administrator moves the project to Snagging, and stays — read-only — once the project is completed. Snags belong to their project; there is no list of snags across projects.

Raising a snag

Add snag opens the snag, and every field saves as you fill it in once it has a title. A snag holds a description — put the location in it, there is no separate field — a scheduled date, one assignee and up to 10 attached files. Assigning a snag to someone notifies them. Under Linked items a snag can be linked to the task, approval or drawing it relates to.

Anyone whose role includes Snagging can edit or delete any snag — unlike site updates, snags belong to the project, not to whoever raised them.

Statuses

A snag is not started, scheduled, in progress or completed, but you only ever choose from three: the first two follow the scheduled date, so a snag with a date reads scheduled and one without reads not started, and you switch it to in progress or completed by hand when the work moves. The date it was completed is recorded for you.

Completed snags drop out of the list; Show completed brings back those finished in the last three months, with a Since date to reach further back. A snag whose scheduled date has passed doesn’t change status — the list is ordered soonest first, so overdue work rises to the top.

What your client sees

Once the project reaches Snagging, the portal gains a Snagging page showing each snag’s status and scheduled date — there is no picking which ones they see. What clients don’t get is who each snag is assigned to, or its attachments, and they cannot raise or change snags themselves. The list is also part of their data export.