What you will learn Not a chapter to read but one to do. Write down every permission in your workspace as it stands, rebuild it around groups rather than individuals, and find the places that need approval.
That last line is the trick. Permissions are not a problem at three people, but three people is when permission design is easy.
Open members and roles and write down every single one.
| Person | Role | Why that role | Last active |
|---|---|---|---|
Count the third. If admins are more than half the workspace, you effectively have no roles.
Erase the names and keep only roles and groups.
| Group | What these people do | Tools needed | Tools not needed |
|---|---|---|---|
Fill in the "not needed" column. Leave it blank and you end up opening everything to everyone. This is where tools are permissions becomes an actual setting.
Grant to groups, not to people. Start adjusting individuals and in six months nobody can describe the current state.
This is the point of the exercise. Find every irreversible action and decide whether it gets an approval step.
| Irreversible action | Who can do it today | Approval? | What to do |
|---|---|---|---|
| Sending email | □ | ||
| Posting externally | □ | ||
| Deleting data | □ | ||
| Payment / ordering | □ |
The picture from pending approval and operator rights belongs here.
Leave the second blank and approvals only accumulate. A queue with no named reader ends in "let's just open it up."
1. Why grant to groups rather than individuals?
Because per-person adjustments make the current state indescribable. Group grants survive people joining and leaving, and auditing happens per group.
2. Why name the reader when you add an approval?
Because approvals with no reader only pile up. Once they pile up, the pile becomes annoying and the answer becomes "just open it," which makes the control meaningless.
3. What is wrong with admins being more than half?
It is the same as having no roles. With everyone at top privilege there is no real control over irreversible actions, and no way to narrow the blast radius when something goes wrong.
Next, how to read usage → Usage and credits
HyperTeams□ 40 minutes□ Workspace admin rights□ Access to the member list□ If the team is still small — do it assuming the people you will add□ How many "why" cells say "because they set it up"?□ Is anyone inactive for more than three months?□ How many admins are there?✗ Kim can use the CRM tool <- an individual✓ The sales group can use the CRM tool <- a groupVerdict: has approval -> leave it no approval, admins only -> fine for now. Revisit as the team grows no approval, anyone can do it -> fix this today□ Which actions could become "anyone drafts, an approver sends"?□ Who will look at that approval queue — write the name down[Today] □ Deal with accounts inactive over three months □ Irreversible actions anyone can do without approval — gate or block them[This month] □ Move individually granted permissions onto groups □ Reduce admins to ( )[Quarterly] □ Fill this table in again□ You listed every member without exception□ There was at least one person whose "why" you could not answer <- if none, you were generous□ You found four or more irreversible actions□ Each approval has a named reader