Roles and permissions
What Owners, Admins, and Viewers can each do.
Specbook has three roles. Permissions are role-based, there's no per-project sharing or fine-grained role customisation in this deployment.
- Owner, full access, including managing other Admins. Reserved for the person (or people) who set the workspace up. There's only ever one Owner per account, and the role can't be assigned from the Members page.
- Admin, everything an Owner can do day-to-day: every project, the catalogue, members, exports. The difference is mostly about who's accountable, not what's possible.
- Viewer, read-only access on assigned projects. Useful for trades, reviewers, and anyone who shouldn't be editing.
Quick reference
| Action | Owner | Admin | Viewer |
|---|---|---|---|
| View assigned projects | ✅ | ✅ | ✅ |
| View every project in the workspace | ✅ | ✅ | ❌ |
| Create / edit / duplicate projects | ✅ | ✅ | ❌ |
| Edit spec sheets, items, attachments | ✅ | ✅ | ❌ |
| Mark sheets complete / reopen | ✅ | ✅ | ❌ |
| Change project status (Draft / In review / Finalised / Archived) | ✅ | ✅ | ❌ |
| Soft delete a project | ✅ | ✅ | ❌ |
| Save / start from / delete templates | ✅ | ✅ | ❌ |
| Manage catalogue entries | ✅ | ✅ | ❌ |
| Generate exports | ✅ | ✅ | ❌ |
| Create / edit / revoke share links | ✅ | ✅ | ❌ |
| View workspace audit log | ✅ | ✅ | ❌ |
| Leave comments on items | ✅ | ✅ | ✅ |
| Invite new members | ✅ | ✅ | ❌ |
| Change member roles (Admin ↔ Viewer) | ✅ | ✅ | ❌ |
| Remove members from workspace | ✅ | ✅ | ❌ |
| Restore soft-deleted projects | ✅ | ✅ | ❌ |
| Change another Owner's role | ✅ | ❌ | ❌ |
When you invite someone, you can assign them as an Admin or a Viewer. The Owner role is fixed at workspace setup and can't be assigned through the invite flow.
Why permissions are coarse
For a single-tenant single-team workspace, fine-grained permissions create more problems than they solve, you end up debugging "why can't I see that project?" instead of doing the work. Coarse permissions mean the team can edit anything. The workspace's safeguards live in the statuses + change-reason model: once a sheet is locked, every edit is recorded.
If your team grows past that model, talk to the Miivo team about adding finer-grained permissions.
What can't be done by anyone
- Permanently delete a project. Soft delete is the deepest delete; restoration is always available.
- Edit someone else's comment.
- Edit a saved change-reason after the fact.
- Modify the audit log.
- Customise the role list.