People and roles

People are invited into your account and hold a role there. This page is about who can do what — and about the four things nobody does without a person saying yes, whatever role they hold. Everything below lives under Settings → Account, in the Members section. The rail row Members & invites goes straight to it.

​

The four roles

Roles decide what someone may do. Approval gates decide what has a consequence. Both apply at once, and the second one is not softened by the first — see How approvals work.

​

Inviting someone

Invite by email in the Members section. Enter their address and choose whether they come in as a member or an admin; the screen states the difference beside the choice. You then get a confirmation step naming the person and the role before anything is sent. Admin is offered to whoever is looking, but only the owner can actually grant it. An admin who chooses it is told to ask the owner to make the change. They do not need an account with us yet — accepting the invitation creates one. Seats are unlimited on every plan, so inviting the whole team costs nothing extra.

​

Reading the members list

One table answers “who is on this account?”, and an invited person who has not accepted yet is part of that answer, so both appear in it. An invitation that has not been taken up has its own menu: resend or revoke. Both are confirmed first, because both are one-way — a resend replaces the link the person is holding with a new one, so the old link stops working.

​

Changing someone’s role

Use the dropdown in their row. It offers Member and Admin — though Admin only takes if you are the owner. An admin who picks it gets the same refusal as on an invitation: only the account owner can make someone an admin. Ownership is not in that list, because it moves by its own deliberate step: open the row menu for an active admin and choose to transfer ownership. You are asked to type the account name to confirm, and the warning on that dialog is the important part — only the new owner can transfer it back. You cannot undo it yourself.

​

Per-person permissions

Some things can be turned on for one person without changing their role. Today there are two switches, one per row:

• Configure automations — letting that person set up work that runs on its own.
• Manage connections — letting them connect, reconnect and disconnect the channels the workspace publishes to.

Owners and admins hold both already, so the switches matter for members. The column header says more controls soon, and it means it: this list grows. A switch you turn on takes effect on that person’s next action. Nobody has to sign out and back in. If you cannot manage a row, the same information is shown as plain text — On or Off — so you can see what someone holds without being able to change it.

​

What a role never buys

Four things stop for a person no matter who is asking:

• publishing something
• spending money or credits
• deleting something
• granting or changing access

An owner holds every permission there is and still meets all four. Permission answers may this person do this at all?; approval answers has someone said yes to this specific thing? They are enforced separately and both have to pass. The same is true of programmatic access: a key carries the permissions of the person who made it, resolved fresh on every call, and never more. See Who can use the API.

​

Two-factor for everyone

Settings → Account has a Security section with one switch: require two-factor sign-in for everyone on the account. It is off to begin with, which means two-factor is each person’s own choice on their profile. Turn it on and everyone here — including you — sets up an authenticator app the next time they open Goosy Bear, and cannot use it until they have.

​

The record

The Activity section at the foot of the same page lists recent changes to people, billing, publishing and security, newest first — who did what, and when. Permission changes and ownership transfers both appear there, so nobody has to remember who was given what.