Invite your team and set roles
Bring teammates into your workspace, pick the right built-in role, and keep guest reviewers separate from internal staff.
On this page
Pogpin separates the people who fix work from the people who review it. Teammates get full accounts with boards and history; reviewers comment as guests with nothing to install. Getting roles right up front keeps your workspace tidy as it grows.
Add a teammate
- Open Settings → Members.
- Enter an email and pick a role.
- They receive an invite link; accepting it adds them to the workspace.
Choose the right built-in role
Pogpin ships four preset roles, each a fixed set of permissions:
- Owner — everything, including billing. There is one owner per workspace.
- Admin — everything except billing: manage members, roles, projects, issues and published docs.
- Member — the everyday role: create and resolve issues, write and publish documents. Read-only on members and settings.
- Viewer — read-only access to projects, issues and members.
Most engineers and designers should be Members. Reserve Admin for the one or two people who own projects and integrations.
Custom roles (Pro and up)
Need something between the presets? On Pro and above you can build custom roles from the permission catalog and assign exactly what a person should touch:
workspace:read · workspace:manage · members:read · members:manage · roles:manage · billing:manage · projects:read · projects:manage · issues:write · documents:write · documents:publish
For example, an external contractor role might get projects:read + issues:write and nothing else.
Reviewers don’t need a seat
External stakeholders never count against your member limit. Share a review link and they comment as guests — their feedback still lands as real pins with full context. See run guest reviews with no accounts for the full flow.
Organize with projects
Spin up a separate project per site or client. Members can belong to many projects, and billing rolls up to the workspace, so you only pay per person once.
Tip: name projects after the environment, not the client — e.g.
acme-staging— so reviewers immediately know which build they’re looking at.