Roles and Permissions

Access control in Bizby has two levels, and they compose. Team roles decide what someone can do in the organisation. Board roles decide what they can do on a given board. This page is about board roles; for team and sub-team administration see Enterprise Readiness.

The permission matrix

	Owner	Facilitator	Editor	Commenter	Viewer	Guest
Open and read the board	Yes	Yes	Yes	Yes	Yes	Yes
Create, edit and delete content	Yes	Yes	Yes	No	No	As invited
Post comments and replies	Yes	Yes	Yes	Yes	No	As invited
React to comments	Yes	Yes	Yes	Yes	No	As invited
Edit or delete someone else’s comment	Yes	Yes	Yes	No	No	As invited
Resolve a thread	Any	Any	Any	Own	No	As invited
Run a timer, present, open a poll or a vote	Yes	Yes	Yes	No	No	As invited
Drive the presentation sequence for everyone	While presenting	Yes	While presenting	No	No	No
Hand control to a named person	While presenting	Yes	While presenting	No	No	No
Be handed control	Yes	Yes	Yes	No	No	As invited, if editor
Follow a presenter	Yes	Yes	Yes	Yes	Yes	Yes
Share the board and change roles	Yes	Yes	Yes	No	No	No
Change the board’s owner	Yes	No	No	No	No	No
Delete the board	Yes	No	No	No	No	No

The board’s owner, and the team’s owner, may always manage the board. Sharing and role changes are open to editors as well, so a team does not have to route every access request through one person; transferring ownership and deleting the board are not.

Facilitator is not a separate stored role. It is a role held during a session: the editor or owner who starts a presentation becomes the facilitator, and the board shows everyone who that is. Only they advance the sequence, jump to a frame or end the session; everyone else follows. They can hand control to a named person from the people list, or another editor can take control, and either way the session keeps its place so nobody following is interrupted.

Who may hold it is governed by the board role, not by who clicks first. The hand-over list offers only people with edit rights; a commenter or viewer shows View only and cannot be made facilitator. Somebody who has gone idle shows Away, so a session is never handed to an empty chair.

The effect is that a workshop needs no elevation and nobody has to be made an owner to run one, while the facilitator’s powers still stop where the role stops: a facilitator cannot change anyone’s access or remove anyone from the board. Those stay with the owner.

Guest is an external participant invited to a single board by email, without a seat on the team. The invitation names them editor, commenter or viewer, and that is the column that applies to them. Guests see only the boards they were invited to, which makes commenter the usual choice for sending work to a client or a reviewer outside the organisation. An enterprise organisation can turn guests off, or require them to use two-step verification.

The comment-only role

A commenter reads the whole board and takes part in every discussion on it, and changes nothing on the canvas. It is the role for a reviewer, an approver, or a stakeholder who should see the work and respond to it without editing it.

A commenter may:

• Place a comment anywhere on the board, or anchored to a particular shape
• Reply to any thread, and be notified of replies to threads they take part in
• React to any comment or reply
• Edit, delete and resolve their own comments and replies

A commenter may not:

• Create, move, edit or delete any shape, frame or page
• Edit, delete or resolve someone else’s comment
• Share the board, change anyone’s role, or change link access

Assign it from Share on any board: choose Commenter beside a team member’s name, or beside a guest’s email address. The same level is available on a shared link, so a board can be sent out for comment without being opened for editing.

How this is enforced

Roles are enforced on the server, not in the interface. Hiding a control is a convenience; refusing the request is the control.

• The canvas. Every board connection is authorised by the server, which decides from the board’s roles whether that session is read-write or read-only. A commenter’s and a viewer’s sessions are read-only, and the collaboration server rejects any change they attempt, whatever the browser sent.
• Comments. Comments are stored on the board itself, so posting one changes the board. A commenter’s comments are submitted to the server, which compares the submission against the board’s current comments and applies it only if every difference is one that person is entitled to make: their own comments added, edited or removed, their own reaction anywhere, and nothing of anyone else’s altered. A submission that would change or remove another person’s comment is refused in full, including one that simply leaves comments out.
• Board data. Database rules independently govern who may read and write a board document, its sharing fields and its ownership, so a client bypassing the application entirely still could not grant itself a role.
• Facilitation. The presenter is part of the board’s shared state, so it is one value everyone reads rather than something each browser decides. Driving the session is refused for anyone who is not currently the presenter, and a read-only session cannot become the presenter at all: the same server decision that makes a commenter’s or viewer’s connection read-only is what withholds it.
• Changes are recorded. Role and sharing changes are written to the enterprise audit log with the person who made them and when.