Guide

Team and access

Who can do what, and how people get in. BrandKind has four roles inside a workspace, and the differences between them are about consequence rather than seniority.

The four roles

Role	In one sentence
`Viewer`	Can read shared work and nothing else. For stakeholders and approvers who should see output without touching it.
`Member`	Can create, edit and publish content. The role most people should have.
`Manager`	A member who also shapes the brand voices everyone writes in, and can see the team and the audit log.
`Admin`	Everything, including who else is here and what the workspace looks like.

Roles are per workspace

The same person can be an admin in one workspace and a viewer in another. Your role is a property of your membership, not of your account — so switching workspace can genuinely change what you are able to do.

What each role can do

	Viewer	Member	Manager	Admin
Read shared content	Yes	Yes	Yes	Yes
Generate, edit and repurpose	No	Yes	Yes	Yes
Send to a destination	No	Yes	Yes	Yes
Create and edit brand voices	No	No	Yes	Yes
See the team list	No	No	Yes	Yes
Read the audit log	No	No	Yes	Yes
Export the workspace’s data	No	No	Yes	Yes
Invite, change roles, remove people	No	No	No	Yes
Change branding and colour theme	No	No	No	Yes
Create sub-workspaces	No	No	No	Yes
Delete the workspace	No	No	No	Yes

Where you cannot do something, BrandKind says so and explains who can, rather than hiding the control. A missing button and a forbidden button look different on purpose — the first suggests a fault, the second tells you who to ask.

Why brand voices are managers and above

A voice is shared infrastructure: every piece anyone generates depends on it. If members could edit voices, one person tuning a voice for a single awkward piece would silently change everybody else's output.

Members can use every voice in the workspace. They simply cannot change one — which is the right trade for something with that blast radius. See Brand voices.

Inviting people

Admins invite by email address and choose the role at the point of invitation. The invited person receives a link, sets a password if they are new, and lands in the workspace with the role you picked.

Invitations that do not arrive

Invitations expire. An expired link says so plainly and can be reissued.
Pending invitations are visible to admins, so you can see whether someone has accepted rather than guessing.
An invitation goes to one address. Check for a typo before assuming a delivery problem.

Changing and removing people

Admins can change someone's role, and the change takes effect immediately. Removing someone ends their access to that workspace only; their account and their memberships of other workspaces are untouched.

Content outlives membership

Removing a person does not remove what they made. Their pieces stay in the workspace, which is almost always what you want — but their private pieces stay private, and nobody else can open them. Ask departing colleagues to share anything the team needs before they go.

The audit log

Managers and admins can read a record of consequential actions — invitations, role changes, removals, deletions, configuration changes — with who did each and when. It is read-only for everyone, and nothing in the product can alter an entry.

It answers governance questions rather than usage questions. For what the system did rather than what people changed, use History.

Your own account

Separately from any workspace, you can change your display name, your email address and your password. These belong to you and follow you across every workspace you are a member of.

Choosing roles well

Default to member. Most people need to make things and nothing more.
Keep managers few. Manager is the voice-editing role; the fewer hands on a shared voice, the more consistent the output.
Have at least two admins. One admin is one holiday away from nobody being able to invite anyone.
Use viewer for approvers. Someone who signs work off rarely needs to edit it.