Users, roles & permissions
Viewer is a real read-only seat, enforced by the database (and genuinely so since 2026-08-25: until then a viewer could reach the accounting write functions directly, because the gate those functions share asked only whether you were not a guest). Somebody on Viewer sees everything a Member sees and cannot change any of it: no creating, editing or deleting a record anywhere in the workspace, whatever screen or tool they reach it through. Four things stay open to them on purpose, because a read-only seat that cannot do them is not usable: asking the assistant, leaving a comment, taking part in chat, and marking their own notifications and calls as seen. Their actions are still written to the audit trail. Those four are the policy and they are not a gap, so the line at the top of a page a Viewer can read but not change has to say exactly that much and no more: “Your role can view this page but not add, edit or delete its records. You can still comment, take part in chat and ask the assistant. Ask an owner or an admin for edit access.” The line it replaces said the role could not change or delete anything on the page, which is more than the seat promises: a working comment box under a banner saying nothing can be changed reads as a permission hole, and it was reported as one. The seat is right and the sentence was wrong. Guest is narrower again: limited to the projects they are added to. TWO SETTINGS USED TO SHARE THIS WORD, AND THEY MEAN DIFFERENT THINGS. An ACCESS LEVEL decides what you may CHANGE anywhere in the workspace, and that is what this paragraph is about. A ROLE decides which PAGES you see at all, which is a different question asked on a different screen. Until 2 September 2026 one of the starter roles was also called Viewer, and joining on the Viewer access level applied it automatically, so the very person this paragraph promises the whole workspace to could open the product and find /tasks, /projects and /invoicing locked instead of readable, and never even see the read-only line at the top of those pages because they could not open them. Both halves are fixed. That role is now called Dashboards and Reports, so nothing in the product answers to Viewer twice, and joining on the Viewer access level no longer applies any role at all. No access level applies a role automatically any more, except a guest: the same thing was happening to an ordinary Member, who was handed a role hiding Tasks, Projects, Drives, Chat and Invoicing, and to an owner, who was handed one hiding the AI agent screens and the forms builder. A read-only person now sees every page, exactly as this paragraph says, and what they may change is decided by their access level on its own. If you want a read-only person narrowed to a few modules as well, that is still available: give them a role on their Access and roles tab, and it will do what its name says. A guest is unchanged, because a guest is already limited to their own projects by the database whatever role they hold. Since 2 September 2026 a control that a person will not be allowed to use is no longer shown to them, and a page you can read but not change now says so in a line at the top with what to ask for and who to ask: a Viewer sees no Save, no Delete and no inline edit rather than pressing one and having nothing happen. The same is true of the per-page Edit and Delete switches in the roles editor. Before that change the database refused the write and said nothing back, so the screen looked as if it had worked until the next reload. One deletion path did not even refuse: anything you remove goes through Trash so it can be restored, and the Trash function ran with full privileges and asked only whether you were a member of the workspace, so the per-page Delete switch had no effect on any of the sixteen kinds of record Trash handles. It asks the same questions the database would have asked now, and says which permission is missing if the answer is no. What a guest CANNOT read, spelled out because until 2 September 2026 a long list of these was readable by mistake: your document and message templates, your project templates, your knowledge base and what the AI chief has learned about your business, your teams and who is in them, your admin-defined dropdown lists (lead sources, loss reasons, supplier categories, deal stages), your shared writing dictionary, your QR codes, your incident write-ups and workspace risks, your AI spend, mail and drive items synced from connected accounts, your OCR queue, and the polls asked about your ideas. A guest keeps exactly what they were invited to: the projects they are on, a community they were added to, and the files in the drives linked to those projects. A check now runs on every change and fails the build if a new table lets a guest read on membership alone.
Open Users to see everyone in the workspace in one list: name, designation, role, team, company and status. Click any person to open their full detail page. Roles and access are managed there (the Access & roles tab) and role templates live in the Users ▸ Roles tab.
- Role templates vs custom permissionsA role template is a saved bundle of permissions and module access you can apply to many people at once (e.g. “Project Manager”).No access level applies a role automatically any more, except a guest, who is given Client guest (since v1.285.0; it was Dashboards and Reports before, a reporting role whose hidden pages included the client portal itself, so an invited client saw a refusal on the one page they were invited to) because the database already limits a guest to their own projects and a short sidebar suits them better than forty pages that would all be empty. Client guest shows the portal, the projects they were added to, their tasks, chat, the calendar and the guide, and hides every internal module. Until 2 September 2026 every access level applied one: an owner became Owner, an admin became Administrator and a member became Team Member. That meant setting somebody’s access level quietly decided a second thing you were never shown, and the Team Member role hides Tasks, Projects, Drives, Chat and Invoicing, so an ordinary colleague could not open the core of the product. Choosing a role is now something you do on purpose, on that person’s Access & roles tab, and it is recorded in the activity log.If somebody has no role at all, their individual toggles apply and every page rule you have not set for them personally defaults to ALLOW. Users ▸ Roles shows anyone in that position, what role fits them and how many pages it would hide, so you can apply it deliberately.
- TeamsGroup members into teams (Users ▸ Teams) for assignment, workload and visibility. A person can belong to more than one team.
- StatusSet a person to Suspended to block access without deleting them; set back to Active to restore.
- 1
Invite someone
Users ▸ invite. They receive a link to set their own password and join the workspace.
- 2
Assign access
Click the person ▸ Access & roles ▸ choose a role template, or toggle individual permissions. Changes save immediately.
- 3
Build a role template
Users ▸ Roles tab ▸ create a template with the permissions and modules it should grant, then assign it to people.
- 4
Check nobody is ungoverned
Page rules only apply to a person once they have a role, and since 2 September 2026 nobody is given one automatically apart from a guest. So Users ▸ Roles listing most of your workspace under “no role” is the normal state and not a backlog: a person with no role sees every page, and what they may change is decided by their access level on its own. Use the list when you WANT somebody narrowed to fewer modules. Open the role first and read what it hides, apply it to one person or to everyone at once, and change anybody’s role afterwards on their Access tab. Every application is recorded in the activity log.
- 5
One role per person, across workspaces
A person carries one role even if they belong to several workspaces, so somebody who is an admin in one and a viewer in another cannot be described by a single role. We do not guess for them: they are listed in the review as needing a decision, and you set their role by hand.
- 6
Start from standard roles
Users ▸ Roles ▸ Load starter roles seeds a least-privilege set of sixteen: Owner, Administrator, Operations Manager, Project Manager, Team Lead, Team Member, Finance Manager, Accountant, Sales Manager, Sales Representative, Marketing Manager, HR Manager, Recruiter, Support Agent, Dashboards and Reports and Client guest. Each is scoped to only the pages it needs (Accountant sees Finance, HR Manager sees People, Sales sees CRM, and Dashboards and Reports sees the dashboard and the reports and none of the operational modules). Administrator hides nothing at all. Owner hides eight pages (the AI agent screens, appraisals, automations, forms, the client portal and the developer tools), which is worth knowing before you hand it to somebody, because four of those eight are on every plan including Free. Every one of them decides which PAGES a person sees, and none of them decides what a person may change: that is their access level, set on their profile. Re-running Load starter roles re-syncs the standard roles to the latest canonical definitions, matching them by name.
- 7
Set page-by-page access (Create / View / Edit / Delete)
On a role (Users then Roles) or a person (their Access tab) open Page access: a collapsible tree of every module (Work, People, Finance, Marketing, Inbox and so on) and the pages under it, each with Create / View / Edit / Delete boxes. Uncheck View to stop that role or user seeing a page; it disappears from their sidebar and search. A per-user setting overrides the role template. How much of this the database enforces varies by page, and the tree tells you which. Turning View off hides the page from the sidebar and search on every page, but it is a decluttering and navigation control rather than a data one: it does not stop the data being read through the API by someone who is otherwise entitled to it. Create / Edit / Delete are refused by the database itself on the pages that carry a server rule, and on the pages that do not yet, unticking them hides the buttons without refusing the write. Where you set a lock we cannot yet honour, a warning appears next to the box, so you are never left believing something is locked when it is not.
Page access (the Create / View / Edit / Delete tree) lets you tailor what each role or person can see and do, page by page. Unchecking View hides a page from their sidebar and search. Treat that as tidying rather than as a wall: what keeps one workspace out of another workspace’s data is tenant isolation in the database, which is always on and is a separate mechanism from these boxes.
Only an owner or admin sets a person’s role, permissions, leave balances, department and email, and they set them on OTHER people from that person’s Access & roles tab. A member can change only their own personal profile (name, phone, job title, avatar, timezone, language, address, emergency contact). This is enforced in the database, not just the screen, so no one can raise their own permissions, even through the API. Since 5 September 2026 that enforcement is a grant rather than only a rule: the only columns a browser can write on a person’s record are the personal ones, and everything else goes through a checked path. Nobody can be added to a workspace any other way than an invitation, and it has to be accepted by the person it was sent to. Resetting a colleague’s password no longer shows you a temporary password: their current one stops working, they are signed out everywhere, and they get a one-time link by email to choose a new one, and you can only do it for somebody whose workspaces you already run. If you cannot change your own role or access, that is why: ask a workspace admin.
Deleting is reversible. Delete a record - on its own or several at once from any list - and it moves to Trash for 30 days with everything attached to it. Restoring brings the whole thing back, not just the record: a task returns with its subtasks, checklist, logged time and custom fields; an invoice returns with its lines and payments; a project returns with its tasks, risks and budget lines. Restore asks you to confirm and tells you how many attached records come back. WHO CAN RESTORE: the person who deleted it, and any workspace owner or admin. Owners and admins get a Workspace trash tab on the Trash page showing what the rest of the team deleted and who deleted it, so a manager can undo a mistake without needing the person who made it, and nothing is stranded when someone leaves. AFTER 30 DAYS an item leaves your Trash but is not destroyed: it moves to your workspace bin and then to a recoverable archive our team can still reach. Nothing is lost just because time passed, and nothing is lost because somebody pressed the wrong button either: Remove moves an item one tier down, and Clear my trash does the same for everything you deleted. Neither destroys anything. WHO DELETED WHAT is recorded for every kind of record, with the person’s name stored at the moment of the delete so it still reads correctly after they leave. Each item carries its own history - deleted by whom, moved out of a bin by whom, when - and the searchable version is in the Activity log, where "Moved to Trash" and "Erased for good" are different words because they are different things. BULK DELETE is capped at 100 items at a time, and at 1,500 attached records in one operation, so a select-all cannot quietly take a workspace with it and so the whole thing finishes well inside the time a request is allowed. A single record can carry up to 3,000 attached records. Over any of those it refuses and tells you, rather than starting and failing. NOTHING IN THE PRODUCT DESTROYS A RECORD ON THE SPOT: Remove moves an item down one recovery tier at a time, and erasing the last copy is something you ask us to do.
The number of people you can add is your plan’s seat limit, shown on the Billing page and in the platform Tenants view (active members count toward seats; guests do not).