Admin Guide
Setting up idaWorks QA, start to finish
Written for the person setting up the workspace for everyone else. It follows the order you actually do things in: people first, then projects, then the checklists and signoffs that run on them. Work through it once and your team can start inspecting.
- 1.Create your account
- 2.Add members and set organisation roles
- 3.Create a project
- 4.Build the folder structure
- 5.Add members to the project
- 6.Create templates
- 7.Apply templates to the project
- 8.Run the signoff process
- 9.Generate reports
Create your account
Sign up with your work email and verify it from the email we send. The person who signs up becomes the owner of the organisation — there is one owner per organisation, and the account cannot be removed or demoted by anyone else.
Your free workspace includes one paid member seat and unlimited free guests, so you can finish this whole guide without adding a card.
Add members and set organisation roles
Start with people, not projects. Everyone you invite lands in your organisation first, and their organisation role decides what they can do everywhere before any project is involved.
There are four organisation roles:
| Owner | Full control. One per organisation, and cannot be removed or demoted. |
|---|---|
| Admin | Manages members and organisation settings, and gets manager access to every project automatically. |
| Basic | A normal member. No administrative powers — what they can do is set per project in step 5. |
| Viewer (guest) | Free and unlimited. Reviews work and completes signoffs. Guests see no templates. |
Seats and guests
Create a project
A project is one job — a site, a building, a contract. It holds the whole structure your team inspects, and it is the boundary most permissions are set against.
Copying a project brings its structure across, and you can choose whether to bring project members and roles and existing signoff assignments with it. Archiving keeps a finished job for the record without cluttering the active list — archived projects are read-only, and you can still report on them.
Deleting is not archiving
Build the folder structure
Inside a project, build a hierarchy that mirrors the real thing — levels, zones, systems, assets. Folders group work; the things at the bottom are what actually get checked and signed off. Getting this right early matters more than anything else in this guide, because your checklists, signoffs, and reports all hang off it.
Duplicate copies a folder and everything inside it — the fastest way to build repeating structures like twenty identical apartments or six identical switchrooms. Build one properly, then duplicate it and rename.
Move relocates a folder and its contents to a different parent. There are limits on how deep a structure can nest, so a move that would push a branch past the limit is refused rather than half-applied.
Add members to the project
Organisation roles and project roles are two separate things. Someone with the Basic organisation role has no powers until you give them a role on a project — that is what this step does.
| Manager | Runs the project. Can manage templates scoped to that project. |
|---|---|
| User | Does the work — fills in checklists and completes items. |
| Reviewer | Reviews and signs off the items assigned to them. |
| Viewer | Read-only access to the project. |
Admins are already in
Create templates
A template is a reusable checklist. Build your inspection once, then apply it everywhere the same checks are needed instead of rebuilding it per folder.
Templates come in two scopes, and the scope decides who can manage them:
| Global | Available across every project in the organisation. Managed by owners and admins. |
|---|---|
| Project-scoped | Tied to one project. Managed by owners, admins, and that project’s managers. |
Every member can see global templates and templates scoped to any project in the organisation. Guests see no templates at all. Moving a template from one scope to another is an owner or admin action.
Naming and coding conventions
idaWorks does not impose a naming system — name and structure things the way your team already works. If you would rather follow an industry standard, many New Zealand construction teams use CBI (Co-ordinated Building Information), a numeric classification system maintained by Construction Information Limited. It organises building information across four hierarchical levels and works well as a naming and coding taxonomy for both your project structure and your template library.
Read the CBI overview on Masterspec →Apply templates to the project
With the structure built and templates ready, add checklists to the items that need inspecting. Pick the template and it becomes a checklist on that item, carrying its checks with it.
From here the two diverge: the template stays as the master copy, and the checklist on the item is where your team records what they found. Editing a template later does not rewrite checklists already in progress on site.
Run the signoff process
Signoffs are how an inspection becomes a record someone stands behind. Assign the people who need to approve an item, and it appears in their queue.
The person doing the work marks each item Pass, Fail, or N/A. Once an item is complete, the people assigned to it either sign it off or raise an issue against it — an issue keeps the item open rather than quietly approving it.
Assigned reviewers find everything waiting on them under My Signoffs, across every project, so nobody has to hunt through the tree. Someone can be assigned to sign off an item without being a member of the project, which is what makes free guests workable as reviewers.
Generate reports
Reporting is where the audit trail becomes something you can hand over. Pick a project — active or archived — then narrow down to what the report should cover by folder, checklist, tag, or status.
Two things come out of it:
- A PDF report — preview it before you generate it, and it carries your organisation's logo.
- An archive of attachments — a ZIP of the photos and documents captured against the checklists, organised by project structure.
Both use the same selection, so what you see on screen is what you get in the export.
Mobile
What's different on the mobile app
The mobile app runs the same product as the browser, so everything above works the same way and is not repeated here. These are the differences worth knowing.
Swipe to open navigation
Swipe right from anywhere to open the navigation rail, and left to close it. Swipes that start on the header are ignored, so the controls up there still work normally.
Press and hold to open a folder
Holding a folder in the project tree for about half a second expands or collapses it, instead of using the arrow.
Tabs are tapped, not swiped
Tapping a tab slides the panel into view. There is no swiping between panels, so a stray sideways swipe will not move you off the checklist you are filling in.
The camera goes straight into a checklist
Photos can be taken directly into a checklist upload, so site evidence lands on the right item without a trip through your camera roll.
Biometric lock
On devices that support it, the app can be locked behind fingerprint or face recognition.
Controls shrink to icons
On small screens, buttons with labels on desktop collapse to just their icon — the Members button, for example, becomes the people icon.
Keep a connection
The app works against your live workspace rather than storing projects on the device, so it is at its best where you have signal or site wi-fi. Worth knowing before a day in a basement.
That's the whole setup
People, projects, structure, templates, signoffs, reports. If something in here did not match what you are seeing, tell us — we would rather fix the guide than leave you guessing.