The three roles
| Role | Members & invitations | Module entitlement | Billing | Audit log | Uses modules |
|---|---|---|---|---|---|
| Platform admin | Yes | Yes | Yes | Yes | Yes |
| Entity admin | Yes | Yes | No | Yes | Yes |
| Member | No | No | No | No | Yes |
The practical difference between the two administrator roles is money. An entity admin runs the workspace day to day — people, access, settings — and cannot change the commercial relationship. That is the role to give an operations lead. Platform admin is the role to give the person who signs the invoices, and there should be at least two of them so a holiday is not an outage.
How modules interpret a role
Every module receives your organisation role and honours it, but modules also have their own internal notions of what a person does — an approver in Sign, an owner in Projects, an agent in the Client Portal. Those are workflow positions, not permissions: they decide whose name is on something, not what you are allowed to open.
The rule that keeps this coherent: nobody rises above their organisation role. A module can grant you a workflow position, and it cannot make a member into an administrator.
When a module mirrors your organisation for the first time, the person who triggered it is created as an administrator inside that module. That is what stops a brand-new module being unadministered. It is scoped to the module and does not change their role in the shell.
Changing somebody's role
Find the person and change the role on their row.
Not on their next sign-in. There is no need to make them sign out.
Role changes are recorded with who made them. A role change nobody can account for is worth a conversation.
There is no self-service recovery for an organisation whose only administrator has left, lost their MFA device, or is unreachable. Recovering it means proving ownership to us. Two administrators costs nothing.
What this does not do
The three are fixed. Requests for a fourth are usually satisfied by module access.
You cannot restrict one person to one project or one customer. Access is per module.
Approvals are a module concept. The shell has no generic approval workflow.
There is no role that grants a module in view-only mode.
Questions
Can somebody be an admin of one module only?
No. Roles are organisation-wide. What you can do is remove their access to the other modules.
Who can see the audit log?
Both administrator roles. Members cannot.
Does a role change affect data they already created?
No. Attribution is historic and does not move.