Trades, tenants & clients
Most of the people who touch a construction job don't work for you. Subcontractors, residents, the client's representative — they all need to see something, and none of them should see everything.
This is the page to read before you hand out the first login. It covers how each of the three outside roles gets access, what they land on, and what they'll ask you.
The principle underneath all three: an outside user doesn't get a reduced copy of your workspace. They get their own surface, built for the one thing they're there to do. That's what makes it safe to give access away freely.
Trades
A trade is a subcontractor working your defects.
How they get in. Usually they don't wait for an invitation. When someone signs up with an email that already appears in your contractor directory, they're enrolled into your organisation as a trade automatically, scoped to their own company's work. The same match happens when you assign work to a trade who already has an account.
A trade working for several builders is linked to all of them, and lands in whichever workspace they most recently did work in. An email that matches nobody's directory doesn't quietly join someone else's workspace — that person is offered a workspace of their own instead.
They may not need an account at all. Assignment emails carry a link that opens the work directly. The screens and actions are identical either way, so a site manager who won't install anything and won't remember a password can still mark work complete with photos.
What they see. Their own assignments, worst-first. Project drawings and documents at project level (never a resident's unit documents), the work orders raised against them, and the ability to raise an RFI. Not other trades' work, not costs, not correspondence.
What to tell them: "Your defects are in the email. Take a photo of the finished work before you mark it complete — it won't let you without one. If a job isn't yours, hit Dispute rather than ignoring it."
Tenants
A tenant is a resident or occupant, usually post-handover.
How they get in. Three routes, and you'll probably use more than one:
- 01A QR card. Print tenant QR cards from Reports and hand them out at handover. The card logs that tenant straight in — no password, no app to install. It's durable, so it keeps working for years.
- 02Scanning a code on site. A resident who scans a location code without an account is offered a short form — name, email, phone. That creates a pending request: the account exists, but the login doesn't work until someone approves it.
- 03Being set up directly by an admin, like any other user.
Approving a request. Pending requests land on a Tenant requests screen. You can correct the name, email, or apartment before approving — worth doing, since these are typed by residents on phones. Approving activates the account and emails a set-password link valid for seven days. Denying deactivates it, ends any active session, and kills any printed card they hold.
Nothing is live until you approve it. A stranger scanning a code in a lobby cannot get themselves in.
What they see. The defects they raised themselves, with cost figures and contractor identity stripped out. The documents attached to their own unit. The project photo gallery. They can raise a defect and comment on one; they can't change a status.
What to tell them: "Scan the card, report anything that's wrong, and add a photo. You'll see it move as it gets dealt with."
Clients
A client is a representative watching progress — the developer's project manager, a consultant, a superintendent.
How they get in. By invitation from an org admin. There is no self-enrolment path — a client account exists because someone decided it should.
What they see. Defects on the projects they're assigned to, read-only, plus the ability to comment and to generate a Client Defect Summary PDF for a defect. No documents, no work orders, no search.
You can narrow it further per project: a client visibility setting limits clients to defects that are already fixed or closed, if you'd rather they saw progress than every raw open issue. See Projects.
If a client needs a document, send it with a distribution, which also gets you an acknowledgement receipt. Widening the role is not the answer.
People with no account at all
Not everyone who needs to be in the record needs a login.
- →[Correspondence](/docs/correspondence) threads can include external participants — a consultant, a superintendent — who read and reply through a link scoped to that one thread.
- →Assignment links let a trade work a defect without signing in.
- →[Distributions](/docs/distributions) send a document to any address and log whether it was acknowledged.
Reach for these before creating an account. A person who will touch your system four times a year is better served by a link than by a password they'll have forgotten by the second time.
Common questions
Can an outside user see other projects? No. Trades, tenants, and clients are bound to the projects they've been attached to, and a request for anything on another project fails as though the record doesn't exist — the refusal doesn't confirm what's there.
Can a trade close their own work? No. They mark an assignment complete with evidence; a manager decides whether the defect closes. See Roles & dashboards.
Can a tenant see what a repair cost? No. Costs and contractor identity are removed from everything a tenant sees.
Someone left the subcontractor — how do I cut them off? Deactivate the user. For a tenant, denying or deactivating also expires any printed QR card, which is the one credential that would otherwise outlive them.
What to read next
- →Roles & dashboards — the full seven-role model and what each can do.
- →Contractors — the directory that trade self-enrolment matches against.
- →QR codes — printing and scoping the codes tenants scan.
- →Documents & drawings — exactly which documents each role reaches.