Projects

A project in IssuesId is the container for everything on a single build — defects, inspections, work orders, RFIs, documents, drawings, distributions, and the team. Most of the platform's per-tenant data is project-scoped, so getting a project set up well at the start saves time everywhere downstream.

Project fields

Each project carries:

→Name (required) and description.
→Address — captured as both a free-form address field and structured fields (addressLine1, addressLine2, suburb, state, postcode, country) so reports and exports format cleanly.
→Project type — picked from the organisation's configured project types (apartments, commercial fit-out, civil, etc.). Use this to group projects in reports and dashboards.
→Start date and practical completion date — used by schedule reports and the defect-liability window.
→Defect liability days — defaults to 90. Defines the warranty window after PC.
→Manager and contact name + email — primary points of contact, separate from project membership.
→Total dwellings — for residential projects, used by per-unit reports.
→Post-construction management — flag for projects continuing into a managed defect-liability period after PC.

Setting a new project up

Creating a project drops you on a setup checklist rather than an empty screen. It sequences the two things that make every later step easier:

01Upload drawings — and run Scan drawings over them to seed the location tree, instead of typing out several hundred rooms.
02Set up Issued To — the contractors this project will be issuing work to.

Steps tick themselves off as the underlying data appears; there's nothing to mark complete by hand. Dismiss the checklist when you're done with it and a Finish setting up banner stays on the project overview so you can come back to it.

Practical completion and the liability window

Set a practical completion date and the defect liability period is derived from it — PC plus your defect liability days, which defaults to 90.

That derived window drives a notice on the project:

→Approaching — inside the last 30 days, warning that after the end date defects are no longer covered under warranty and a charge will apply.
→Passed — the same message in the past tense.

Tenants see the notice as well as your own team. Trades and clients don't. It exists so nobody is surprised by the first invoice after the window closes, which is otherwise one of the more reliable sources of a difficult phone call.

Project membership

Project membership is separate from organisation membership. A user can be in your org but not on a specific project — and that's how the platform keeps scope clean:

→Add a user to a project to grant them visibility and the role-appropriate actions on that project.
→Remove them when they roll off — historical records they touched (their captures, transitions, sign-offs) stay attributed to them.
→Some roles (notably Tenant and Client) only ever see the projects they're explicitly added to.

The search and reports surfaces both honour project membership: you don't see documents, users, or records from projects you're not a member of.

Per-project workflow rules

Each project carries its own workflow rules as JSON on the project record. This means:

→A high-rise residential project can have different escalation timings than a small commercial fit-out.
→Cloning a project's rules to a new project is straightforward.
→Workflow rule changes are scoped — you can adjust escalation on one project without affecting others.

Milestones

A project carries its own list of named milestones — slab down, lock-up, services rough-in, practical completion, whatever the programme calls them. They live under project settings, alongside sign-off and coordinator configuration, and are visible to anyone who can see project settings.

→Add one at a time, by name. There's no template and no org-wide list: milestones are defined per project, deliberately, because two jobs rarely have the same programme.
→Tick the checkbox to mark one complete. There's no confirmation step — it's a checkbox, and unticking is the undo.
→Completing one records who ticked it and when, taken from the session rather than anything the browser sends.
→Renaming a milestone doesn't touch that record. The name can change after the fact without rewriting who completed it or when.
→If the user who completed it is later removed from the organisation, the completion and its timestamp remain. Only the name attached to it goes.

Milestones are a record of dates that landed, not a scheduling tool. There are no dependencies, no baseline dates, and no gantt.

Notification emails

A project has a notification email list — a free-form array of email addresses that receive project-level notifications (typically off-platform stakeholders like a consultant, principal contractor, or owner's rep). These addresses don't have user accounts; they just get the notification.

Per-project category exclusions

The defect category taxonomy is org-wide, but not every category is relevant on every project. Each project can exclude specific categories — they disappear from the picker for that project's team without affecting other projects in the same organisation.

Exclusions are additive on top of the org-wide list: a category that's active at the org level can be turned off per-project, but you can't add a project-only category that isn't in the org taxonomy. Edit the org taxonomy if a category is needed somewhere it's not yet listed.

Client visibility setting

Projects have a client_defect_visibility setting that controls what users with the Client role see:

→`all` (default) — clients see every defect on the project. Matches the original behaviour.
→`fixed_only` — clients see only defects whose status is fixed or closed. Useful when you want the client to see progress without seeing every raw open issue.

The setting is applied at the API layer — you can't bypass it by hitting a different endpoint.

Soft delete (archive)

Projects aren't hard-deleted. Setting a project inactive removes it from default lists, but every defect, inspection, document, and audit record on it stays in the database. This keeps reports from prior periods accurate and preserves the audit trail.