Roles, Permissions and Visibility in Openbook: A Setup Guide

Access control in most collaboration tools fails in one of two directions. Either everything is open and you discover the intern can edit the compensation sheet, or the permission system is so elaborate that nobody can tell you why Priya can't see the board she works on daily — and fixing it requires the one admin who configured everything and left in March.

Openbook's model is deliberately simpler than the second kind and safer than the first: four roles (Owner, Admin, Member, Viewer) applied at the space level, plus per-room visibility for the exceptions. Two levers. You can hold the whole model in your head, explain it to a new admin in five minutes, and still handle the real cases — clients, contractors, sensitive HR work, leadership rooms — without a consultant.

This guide is the full setup walkthrough: how the hierarchy shapes access, what each role should be used for, when to reach for per-room visibility, the standard patterns for external and sensitive access, what the Business plan adds, and how to audit the whole thing quarterly so it stays true.

The hierarchy is the first permission system

Before touching a single role, understand that Openbook's structure — Organization → Space → Room — does most of the access-control work by itself.

The organization is your company's tenant. Openbook is multi-tenant: your organization's people, spaces, and data are yours, cleanly separated from every other customer. Membership in the organization is the outermost gate — no one outside it sees anything.

Spaces are workspaces for teams, departments, projects, or communities, and — this is the load-bearing fact — each space has its own members and its own roles. Someone can be an Admin in the Marketing space, a plain Member in the company-wide space, and not present at all in the Finance space. Space membership is your primary access boundary: the cleanest way to keep the sales team out of the engineering backlog is not a permission rule, it's that they were never members of that space.

Rooms are the working surfaces inside a space — boards, docs, feeds, and the rest of the 18 room types. By default a room is there for the space's members; per-room visibility lets you narrow any single room to certain people when the default is wrong.

The design consequence: most "permission problems" are actually space-design problems. Before writing restriction rules, ask whether the audiences are simply different — and if they are, give them different spaces. A company that creates one giant space and then fights it with room restrictions is doing hard mode voluntarily.

The four roles, and what each is actually for

Within a space, every member holds one of four roles. Here's the practical read on each:

Role	Use it for	Rule of thumb
Owner	Ultimate responsibility for the space	One or two people, never zero after someone leaves
Admin	Running the space: rooms, members, settings	The few people doing structural work
Member	Doing the work	Almost everyone
Viewer	Reading without touching	Stakeholders, execs, clients, auditors

Owner is accountability, not a power-up for busy people. The Owner answers for the space existing, being structured sanely, and having the right admins. Keep the count low and — the mistake every org makes once — make sure ownership is reassigned before an owner offboards, not after.

Admin is the janitor-with-keys role: creating and arranging rooms, managing members, adjusting settings. Resist the flattery cycle where Admin becomes a status badge. Every unnecessary admin widens the set of people who can accidentally restructure the team's workspace, and — more subtly — dilutes the sense that anyone in particular tends the garden. Two or three per space is plenty.

Member is the default, and it should feel generous: members do the actual work — cards, posts, docs, questions, retro cards, check-in responses. If you find yourselves wanting members to have less than the member experience in a particular room, that's per-room visibility's job, not a reason to demote people to Viewer.

Viewer is the quietly strategic role. A Viewer sees the work without being able to change it — which is exactly right for the executive who wants the dashboard without the ability to drag a card, the stakeholder following a Project Status room, or the client watching delivery. Viewer is what lets you say yes to "can I see how it's going?" without saying yes to accidents. Teams that never use Viewer end up either over-inviting (stakeholders as members, chaos ensues) or under-sharing (stakeholders excluded, meetings ensue).

Per-room visibility: the scalpel

Space membership is the broadsword; per-room visibility is the scalpel. Any room can be visible to everyone in the space or only to certain people — and that one switch covers nearly every legitimate secrecy need inside a team:

• The HR space's compensation-review board, visible only to the two people running the cycle, while the onboarding board stays open to the whole People team.
• A leadership room inside the company space — a private Docs room for management notes — invisible to everyone else, without exiling leadership to a separate tool.
• Draft communications. The comms team preps the reorg announcement in a restricted room, then posts to the open Feed when it's real. Staging areas are legitimate; what matters is that the destination is open.
• An M&A or incident workroom — genuinely need-to-know work that would be reckless in the open, scoped to exactly the people handling it.
• Pre-launch surprises — the peer-nominated awards board before the party, the acquisition doc before the signature.

Notice the shape of every good example: restriction is specific, temporary or structural, and explainable in one sentence. "Only the review committee sees the review board" explains itself. If you can't state in one sentence why a room is restricted and who decided, the restriction is probably habit, not policy — and habit-restrictions are the ones that rot into "nobody knows why this is hidden, so nobody dares open it."

One related mechanism worth knowing: Group rooms — Openbook's member-run communities for ERGs, guilds, and clubs — carry their own open/closed privacy with self-serve join and leave. Open groups let anyone browse and join; closed groups gate membership at the group's own door. That's community privacy, governed by the community, and it means you don't spend admin-level visibility controls on what is really a membership question.

Default to open — then justify every exception

Openbook's model supports secrecy where it's needed, but the strong recommendation is a default-to-open posture: rooms visible to their space, work happening where colleagues can see it, restriction as the marked case rather than the ambient one.

The reasons are practical, not ideological. Open rooms make work discoverable through the global ⌘K command search — a restricted room's contents help no one who doesn't already know they exist. Open rooms let the AI assistant and your teammates build on context instead of re-asking for it. Open rooms kill the meeting-to-find-out genre. And openness compounds culturally: people narrate their work in public rooms exactly to the degree that public rooms are where work happens. The fuller argument — including the honest limits of transparency — is in Default to Open: the case for transparent internal communication.

The operational version of the principle fits in three lines:

1. Space membership decides who's in the building.
2. Rooms default open to the building's occupants.
3. Every "certain people" room has a named reason and a named decider.

Pattern book: five setups you'll actually need

Here are the configurations that cover most real organizations, from simplest to most sensitive.

1. A single team space

Everyone's a Member, one or two Admins, one Owner, all rooms open. Genuinely the right answer for most teams under twenty people — don't add structure you don't need. Add your first Viewer the day a stakeholder asks to follow along; add your first restricted room the day you're staging a surprise or a draft. If a year passes without either, you've lost nothing.

2. Departments plus a company-wide space

The standard mid-size shape: every employee is a Member of the company-wide intranet space (feed, events, Time Off, handbook), and each department has its own space with its own membership and admins. Cross-department visibility is granted the honest way — by adding people to spaces, usually as Viewers first. This is the architecture behind using Openbook as your company intranet; the one-space-per-company-with-heavy-restrictions alternative recreates a permission labyrinth and should be resisted.

3. Client access (the agency pattern)

Agencies run one space per client, and the client joins their own space — nothing else exists for them, because space membership is the outer wall. Inside the client's space:

• Client-facing rooms are open: the Feed for updates, a Dashboard wired to delivery boards, an Event room for milestones and reviews, and — the room clients love — Proofing, where reviewers pin annotations on the work and give formal approve/changes-required decisions. Approval workflows only work when the client can genuinely reach the room.
• Internal rooms are visibility-restricted to staff: the real production board with its honest estimates, the internal retro, the scoping doc. Same space, invisible to the client.
• Role choice sets the relationship: clients as Viewers for a watch-and-comment-in-review dynamic, or Members when they should post briefs and join threads. Decide per client, deliberately.

The full agency operating model is in running an agency on Openbook.

4. Contractors and freelancers

Add contractors only to the spaces they work in, as Members there and nothing more — no company-wide space membership unless they're genuinely embedded in company life. Restrict any room in those spaces that carries beyond-engagement material. Then treat their access as a dated liability: note the engagement end alongside the engagement itself, because the classic failure is the freelancer whose access outlives their invoice by a year. (The audit below exists largely for them.)

5. Sensitive functions: HR and finance

Sensitive teams get their own spaces (outer wall), and then use per-room visibility within them, because sensitivity is not uniform even inside HR: the Q&A room answering benefits questions should be broadly visible, the recruiting Table Board team-visible, the compensation and ER (employee relations) rooms restricted to the handful who must see them. Layered, not bunkered. The full people-team setup is in Openbook for HR and People teams.

Choosing roles for real people: a worked walkthrough

Abstract role definitions get easier when you walk an actual cast of characters through them. Take a product team's space — Kanban board, Check-in room, Retrospective room, Docs, Dashboard — and assign everyone who might plausibly want in:

• The team lead — Owner. Accountable for the space's shape, first call when structure questions come up.
• The senior engineer who reorganizes the board every quarter — Admin. She's the one actually doing structural work; the role matches the behavior.
• The six people building the product — Members. They move cards, answer check-ins, add retro cards, write docs. The default role for the default relationship to the work.
• The VP two levels up — Viewer. He wants the dashboard and the sprint's shape, not edit rights he'd never use and could misfire. Viewer gives him standing sight without standing risk — and spares the team the "is the VP watching this column" performance anxiety that comes from an exec with a Member badge.
• The designer who's embedded half-time — Member. Half-time embedded is still embedded; people doing the work get the working role, regardless of reporting line.
• The account manager from the client's side (if this were client work) — Viewer or Member per the pattern book above, decided deliberately at kickoff, not defaulted.
• The data analyst who needs numbers monthly — Viewer, and honestly even that mostly for the Dashboard room. If the space's only value to someone is one room, that's a hint the room (or a summary version of it) might belong in a broader space instead.

The exercise generalizes: for each person, ask what they do in the space — run it, build in it, or watch it — and the role falls out. When you can't answer what someone does there, the answer is usually that they don't belong in the space at all; send them a link to the open rooms' outputs instead.

Joiners, movers, leavers: access as a lifecycle

Most access mess isn't created by bad decisions — it's created by good decisions nobody revisited. Handle the three lifecycle events explicitly:

Joiners. A new hire's day-one grant is: the organization, the company-wide space as Member, and their team's space as Member. That's it — three moves, and the people directory and org chart pick them up as a side effect of membership, no separate profile chores. Additional spaces come later, pulled by real work rather than pushed by optimism. Over-granting on day one feels welcoming and audits terribly.

Movers. An internal transfer is a remove and add, not just an add. The instinct to leave old access "in case it's useful" is how a company ends up with senior people holding member rights in nine spaces they haven't opened since 2024 — nine spaces whose restricted rooms and sensitive boards they can technically still see. Move the person, close the door, and let them re-request the odd old space if a genuine need survives the move.

Leavers. Offboarding is organization-level: remove the person from the organization and every space, room, and role goes with them — the multi-tenant wall doing its job. On the Business plan, SSO/SAML collapses even that into disabling one identity-provider account, and the audit log lets you verify after the fact that departure and access-end actually coincided. Whatever your plan, write the access step into the offboarding checklist itself; access removal that lives in someone's head leaves with that someone eventually too.

What the Business plan adds

The Free and Pro plans include the full role model and per-room visibility described above. The Business plan ($15/user/month, $12 annual) adds the layer that IT and security teams ask about when a tool becomes company infrastructure:

• SSO/SAML — sign-in through your identity provider, which turns offboarding from "remember every tool" into "disable one account." For access hygiene, this is the single biggest upgrade money buys.
• Audit log — a record of what happened, for the compliance conversations where "we believe so" isn't an acceptable answer.
• API access — programmatic reach into the workspace, including for provisioning and reporting driven by your own systems.
• Advanced permissions — finer-grained control for organizations whose obligations outgrow the two-lever model.
• Plus a 99.95% uptime SLA and dedicated support.

The honest upgrade trigger isn't headcount; it's obligation. The day a customer's security questionnaire, an auditor, or your own incident-response plan asks "who accessed what, and how do you know?" — that's the day the audit log and SSO stop being nice-to-haves. Details at pricing.

The quarterly access audit

Permissions are set once and drift forever: people change teams, contractors finish, "temporary" restricted rooms turn three years old. A quarterly audit — an hour, honestly — keeps the map matching the territory. The checklist:

1. Walk the spaces. For each: does the member list still match the team? Remove ghosts — people who changed roles and kept old access out of nobody-got-around-to-it.
2. Check the top of each space. Every space has a living Owner (not someone who left) and two-ish Admins who actually still do admin. Fix orphaned spaces on the spot.
3. Review every "certain people" room. For each restricted room, re-ask the one-sentence question: why, and says who? Open the ones whose reason has expired — finished staging rooms, launched surprises, last cycle's review board. Restriction should require ongoing justification; openness shouldn't.
4. Sweep external people. Every client, contractor, and partner account: still engaged? Right role? Clients who became Viewers "for the project" that ended in Q1 get removed today.
5. Confirm Viewer discipline. Stakeholders who've been Members-out-of-politeness get moved to Viewer; nobody loses face, and the accident surface shrinks.
6. On Business: sample the audit log. Not a forensic review — a habit. Ten minutes of "does anything look weird" per quarter is how you find the weird thing in quarter two instead of year two.

Tie the audit to something you already do quarterly — planning, the board meeting prep, the ops review — because an audit with no anchor is an audit that happens once.

Mistakes to design out from the start

Five failure modes account for most permission pain; name them early and they mostly don't happen:

• Everyone's an admin. Handed out as courtesy, paid for in accidental restructuring and in nobody feeling responsible. Admin is a job, not a compliment.
• The bunker. Restricting by reflex until the workspace is a corridor of locked doors. Costs discoverability, search value, and trust; delivers almost nothing the outer space wall wasn't already delivering.
• One mega-space fighting itself. Using room restrictions to simulate what should have been separate spaces. If the exception list is longer than the member list, the space is wrong, not the permissions.
• Stakeholders as Members. Over-granting because Viewer felt stingy. Viewer is the respectful role: full sight, zero risk.
• Offboarding by memory. Access removal that depends on someone remembering. The quarterly audit is the safety net; SSO on Business is the real fix.

Next steps

Setting this up takes an afternoon, not a project:

1. Draw the spaces first — the audiences, not the org chart. Most access control is space design.
2. Assign roles stingily: one or two Owners, few Admins, everyone else Member, watchers as Viewer.
3. Open by default; restrict with a sentence. Every "certain people" room gets a reason and a decider on record.
4. Adopt the pattern that fits — team, department+intranet, client, contractor, or sensitive-function — from the pattern book above rather than inventing your own.
5. Put the quarterly audit on the calendar now, attached to a ritual that already exists.

The role model and per-room visibility are available on every plan, including Free — $0, unlimited rooms and members, all 18 room types — so you can build the whole structure before spending anything; see roles and permissions for the feature overview, pricing for the Business-plan controls, and /product for how the rest of the platform fits around them.

Two levers, honestly pulled: enough structure to be safe, not enough to need a map. That's the whole system — set it up once, audit it quarterly, and get back to work.