Defects

A defect in IssuesId is any tracked site issue — a quality problem, a variation request, or a backcharge claim. Every defect carries a full lifecycle with role-gated transitions, so the audit trail holds up in claims, disputes, and PC sign-off.

The lifecycle

Defects move through a fixed sequence of states:

01Open — the default state when a defect is first captured. Not yet assigned to anyone.
02Assigned — sent to a trade or sub-contractor.
03Pending — work in progress, awaiting completion.
04Fixed — the trade has marked the issue as resolved.
05Trade completed — sub-contractor sign-off that the fix is genuine.
06Ready to inspect — handed back for verification.
07Closed — verified and signed off. Terminal state — closed defects can't be re-opened.

Two additional states sit outside the happy path:

→Outstanding — used as an escalation or exception flag when a defect can't progress through the normal path (e.g. blocked by a design decision, missing material, dispute resolved against the assignee).
→In dispute — set automatically by the system when an assignment is disputed. Users can't transition into this state manually; it's derived from underlying assignment activity.

Each transition is role-gated. A contractor can't close their own work, a supervisor can't be bypassed, and every state change is timestamped against the user who made it.

Capturing a defect

The capture flow is intentionally short — under 30 seconds for an experienced user.

→Photo — one or more, taken in-app or imported from camera roll.
→Location — drop a pin on the project drawing, or scan a QR code that pre-fills it.
→Dictation — a mic on the description field, whether you're raising a defect on the phone or at a desk, or editing one. What you say is added to what's already typed, never swapped for it.
→Raised by — who reported it. Picked from the project's reporter directory, so a tenant's complaint stays attributable months later. See below.
→Classification — what kind of defect this is (e.g. Plumbing, Tiling, Water Leak — Bathroom Membrane). Optional. See below.
→Trade and priority — drives routing and SLA timing.
→Type — what the record is: Defect, Safety, RFI, General, Maintenance, Warranty, Incomplete Works, Contract Variation, or Variation. Defaults to Defect. See below.
→Cost category — defect, variation, or backcharge. This flag follows the record into reports.

Defect numbers

Every defect gets a number made from its project's key and a sequence, like ABC-001, and the same number appears on every screen, PDF and email. The key is set on the project; see Projects. Search for the number from the top bar and that defect comes first.

Type, Classification, and Cost category

Three fields that sound alike and do different jobs. Worth getting straight once:

→Type answers what kind of record is this? It's a fixed list of nine — Defect, Safety, RFI, General, Maintenance, Warranty, Incomplete Works, Contract Variation, Variation — and it separates a genuine defect from incomplete works, a warranty claim, or a variation that shouldn't be counted against your defect numbers at all. Defect lists filter on it.
→Classification answers what's wrong, and whose trade is it? That's the org's own taxonomy, described below.
→Cost category answers who pays? Defect, variation, or backcharge.

A leaking shower on a completed unit could be Type Warranty, Classification Water Leak — Bathroom Membrane, Cost category defect. Each field is read by a different person for a different reason.

Classification

Classification is the field the defect lists sort and filter on, and it's what the app calls the org's defect taxonomy. (The settings screens where you edit the list still call these categories — same thing.)

The field uses an organisation-wide taxonomy — a configurable list of defect types that's shared across every project in your org. New organisations are seeded with ~80 sensible defaults covering trades (carpentry, plumbing, electrical, …), failure types (chip / scratch / mark / dent, water leak — and a dozen sub-types of that), and admin entries (duplicate entry, not a builder's defect, waiting on image).

You can edit the taxonomy any time:

→Add or rename entries to match your team's vocabulary, in Organisation Settings.
→Reorder them in the picker.
→Deactivate entries that no longer apply, without destroying historical defects that used them.
→Exclude per project — an entry that's relevant on most jobs but not on a specific one can be turned off for that project, keeping the picker tight for the team on site.

Classification is optional on a defect — captures without one are still valid records. It's there to help filtering, reporting, and trade-routing, not to gate the capture flow. It shows as a column on the defect list, so an uncategorised defect reads as an em-dash rather than a blank.

Who raised it

Every project keeps a reporter directory — the people who raise defects on that job, whether or not they have a login. A reporter carries a name, a role (tenant, client, consultant, and so on), contact details, and optionally the location they're attached to.

→Reuse across projects. Start typing and the directory searches your whole organisation, so a consultant who appears on four jobs is entered once and copied, not retyped.
→Contact details are enforced where they matter. Tenant and client reporters require contact details — those are exactly the reporters you'll need to reach when the defect is disputed.
→Tenants seed themselves. A tenant who claims their unit by QR code or accepts an invite gets a reporter row automatically, linked to their user account. Edit their profile and the change follows them across every project they appear on.

On the defect form, Raised by is a picker over that directory, with an inline "add new reporter" option so nobody has to leave the capture flow. Defects raised by a tenant pre-fill to their own row.

Issuing to a trade

Issuing a defect to a contractor emails them. Before you save, the Issued To dialog and the new-defect form list exactly who is about to be emailed, and flag any contact with no email address on file, while there's still time to add one. What the email contains, and the settings that shape it, are in Notifications.

→Hold the email until you're ready. A project can be set to hold the trade's email until someone presses Send. Issuing then records the trade but sends nothing, and the defect shows Not yet sent with a Send button. Useful when a defect is issued while it's still being written up. It's off by default, and switching it on doesn't hold anything already issued.
→Every email on the record. Emails a defect sends appear on its audit trail. Company Admins and Managers can open one to see exactly what the recipient got and whether it was delivered or bounced, and resend it.

Issued-To sign-off

Assigning a defect to a contractor tells them to do the work. Sign-off is the separate, explicit step that records someone accepting it as done.

An assignment's sign-off is in one of three states — none, requested, or signed off:

→Request sign-off — asks the configured approver to review the completed work. The approver is notified.
→Sign off — records the acceptance, against a named person and a timestamp, with an optional note. Approvers can sign off without a prior request; everyone else has to go through one.
→Revoke sign-off — reverses it, and stays in the history rather than erasing the original.

Which roles can approve is configured per organisation. The point of the separation is that "the trade says it's done" and "we accept it as done" are different claims, made by different people, and a defensible record keeps them apart.

Filtering the list

The defect list carries a filter set built for the questions people actually ask on a job, not a generic table filter:

Filter	Answers
Issue Number	"Pull up 214, 218 and 231." Multi-select with type-ahead.
Location	Anywhere in the location tree.
Type, Classification, Priority	The three descriptive fields, filtered independently.
Issued To	Whose work it is.
Cost To	Who's wearing the cost, which isn't always the same contractor.
Cost attribute	Defect, variation, or backcharge.
Reporter / Inspected By, Entered By	Who raised it versus who typed it in — different people, and the difference matters when you're chasing detail.
Contact	The person on record for it.
Room	"Every bathroom." Rooms by name across every lot, with a count beside each, so one pick covers what would otherwise be hundreds of locations. Also on All Defects and in Reports.
Logged, Fix by, In Progress, Closed dates	Four independent date ranges.

Active filters show as chips above the list, so you can always see why a list is as short as it is. Status reads as a colour-coded pill rather than a word you have to parse, and the columns are per-user — show, hide, drag them into the order you want, and drag their edges to resize them. The list remembers your layout in that browser. The list you want at handover isn't the list you want mid-build.

The search box matches every field on a defect, not just the description: the number, the location and the levels above it, the Issued To company, contact and email, who raised and who entered it, the classification, access notes, the linked work order and Cost To. On All Defects it matches the project name too. Matches are highlighted, and when the hit is in a column you've hidden, the row says what it matched on. Press / to jump to the box. When a search finds nothing, it offers the likely fix in one click: include closed defects, a close spelling, or the same search across all projects.

Cost tracking

A defect carries two contractor links, and the distinction matters when it comes time to invoice:

→The assignee (set per assignment) is the contractor doing the work. They get the notification, they update the assignment status, they sign off when complete.
→The cost-to contractor is who gets billed for the work. It's set per-defect, separate from any assignment.

Most of the time these are the same. The split exists for the cases where they aren't — for example, when Trade A is doing the rework but Trade B caused the issue and is being backcharged, or when an internal team handles the fix but an external party is billed. The cost-to contractor field captures that intent in a structured way, so reports and exports reflect who actually pays.

The defect also carries an optional cost value and a cost code (drawn from the project's configured cost code list). Together with the cost category (defect / variation / backcharge) and the cost-to contractor, that's a complete record line for the accounts team.

Comments & notes

Every defect has a conversation thread — internal and shared comments attached to the record. Each note has:

→An author, recorded at the user level.
→A visibility scope — one of:

- internal — only your own team sees it. - shared_trade — visible to assigned trades. - shared_tenant — visible to the tenant scoped to this defect's unit. - shared_client — visible to client-role users on the project. - shared_all — visible to everyone who can see the defect.

→An optional assignment link — notes can be tied to a specific assignment thread when context matters (e.g. back-and-forth on a particular trade's rework).
→Edit tracking — if a note is edited after posting, the edit timestamp is recorded and a revision count is incremented. Recipients see "edited" markers; the platform doesn't pretend the edit didn't happen.
→Soft delete — a deleted note leaves a tombstone, not a hole. The thread shows that something was removed and when, without exposing the content.

Response templates keep standard replies consistent. Company Admins write them in Settings › Response templates, and anyone can drop one into a defect's conversation, the close dialog or the sign-off page with Use template. Placeholders such as {{defect_number}}, {{project_name}}, {{issued_to}} and {{raised_by}} fill in from the defect, and nothing is sent until you post it.

This is the surface that replaces the old fixed "internal notes / client notes / builder response" columns. The conversation model means a defect's discussion can be longer than three messages and audited just as cleanly.

Time-in-progress tracking

The first time a defect transitions out of open — when work actually starts — the platform stamps an in-progress timestamp on the record. Once set, it's never cleared and never updated. That gives reports and dashboards a clean "time-in-progress" measure that's independent of when the defect was first captured.

The defect list endpoints support inProgressFrom and inProgressTo query parameters to filter on this date range — useful for SLA reports, aging analyses, and "what got picked up this week" queries.

Annotations

Photos and drawings support overlay markup:

→Pin — drop a numbered pin with an optional caption.
→Circle / arrow / text — call out the exact problem area.
→Voice caption per pin — speak instead of typing.

Pin colour reflects status, so a foreman scanning a plan sees open issues at a glance.

Disputes and history

If a trade disputes a defect (e.g. claims it's design intent, not a fault), they raise a dispute. The defect pauses in its current state until a supervisor adjudicates. Both the dispute reason and the resolution are recorded.

Every defect has a full history view: who did what, when, with what evidence. This view is the source of truth in claims and contract disputes.

Bulk actions

For projects with hundreds of defects, filter the list, tick the defects you want, and act on the whole selection at once:

→Raise work order — one work order linked to every selected defect.
→Add Issued To — add a company or contact without replacing anyone already issued.
→Change Issued To, Change Status and Change Reported by.
→Add note — post one note to every selected defect, at any visibility, with the option to send no notifications.
→Sign off — after a verified inspection sweep.

Exports of a filtered set come from Reports.