Roles
Every member of a workspace holds exactly one role. Roles are set when you invite someone and changed in Settings → Members.
| Role | Can | Cannot | Billed |
|---|---|---|---|
| Owner | Everything, including billing and deleting the workspace | — | Yes |
| Admin | Manage members, portals, the GitHub connection and views; everything a member can do | Change billing; delete the workspace | Yes |
| Member | Create and edit issues, comment, move cards, use and save views | Manage members, portals or the GitHub connection | Yes |
| Viewer | Read Issues, Projects and Portals | Create, edit or comment on anything | No |
Choosing a role
Section titled “Choosing a role”- The person who needs to see status and nothing else is a viewer. It costs nothing and there is no separate cut-down screen: a viewer sees exactly what a member sees, without the ability to change it.
- The person who triages and edits work is a member.
- The person who configures a portal, its request types and its destinations is an admin. Managing portals is admin-scoped.
- The person who holds the card is the owner. There is one owner at a time; transferring it is changing a member’s role to Owner in Settings → Members. The workspace’s last owner cannot be changed to another role until someone else is made owner first.
What no role can do
Section titled “What no role can do”No role can see another workspace’s data, and no role can see the GitHub App’s private key or a raw installation token. Those exist only as server secrets and are never shown in any screen, log or export.
A role also cannot exceed what GitHub itself allows. If GitHub refuses a write — because the installation does not cover that repository, or the permission was not granted — Pealboard shows GitHub’s refusal and changes nothing.