> ## Documentation Index
> Fetch the complete documentation index at: https://docs.utmkit.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Members and roles

> The four roles a workspace seat can hold, what each may change, and how to invite, re-assign and remove people.

Every person in a workspace holds one of four roles. The role decides what they may **change**; anyone in the workspace may read its links, campaigns, reports and rules. The exception is the [activity log](/en/workspaces/activity-log), which owners and administrators alone can open.

Roles are per workspace. The same person can be an owner in one workspace and a viewer in another.

## The roles

**Owner** — can do everything below, and is the only role that decides how the workspace itself works: creating workspaces, requiring two-factor authentication of everyone, and setting up single sign-on. A workspace always keeps at least one owner. The organization's billing is also an owner's call.

**Administrator** — runs the workspace day to day. Administrators manage the rules (the UTM convention, approved values, dependency rules), accept audit findings and confirm remediations, manage custom domains, branding and shared client reports, invite and remove people, change roles, and read the activity log. An administrator cannot act on an owner.

**Member** — the working seat: creates, edits and deletes links and campaigns, and uses the assistant for the same. Members do not change rules, domains, branding or seats. An owner or administrator can lock a member to approved values for chosen UTM parameters, so the member cannot coin new ones.

**Viewer** — for an agency, the client. Viewers see everything in the workspace, ask the assistant about it, and change nothing. The assistant simply never offers a viewer a tool that writes.

## Inviting somebody

Owners and administrators invite from [Members](https://app.utmkit.co/members) with **Invite somebody**: an email address and a role.

The person receives one short mail saying they have been invited to join the workspace, with a link to accept; if the workspace requires two-factor authentication, the mail says so up front. Following the link signs nobody in: the visitor is asked to sign in as the invited address or, if they have no account yet, to create one with that address. They then land inside the workspace with the role you chose.

Until it is accepted the invitation is listed under **Invited, not yet accepted**, with its expiry. Re-inviting the same address refreshes the invitation and replaces the earlier link. **Revoke** kills it; a revoked, expired or already-used link shows the same "no longer valid" answer to whoever holds it.

<Note>
  The console answers "Invitation sent" whether or not the address already has an account, on purpose: an invitation addresses an email, not a person, and the page never reveals who is a user.
</Note>

## Changing a role

Whoever may manage members changes a role from the dropdown on that person's row, as long as they outrank or equal that person; an administrator cannot demote an owner or promote anyone past themselves. The change takes effect on the person's very next action: their open pages reconnect and pick up the new role.

Demoting the last owner is refused: make somebody else an owner first.

## Removing somebody

**Remove** on a member's row takes them out of the workspace immediately; their open pages fall back to another workspace of theirs, or to none. The same last-owner rule applies. Leaving a workspace yourself is the same action on your own row.

## Two-factor authentication on this page

Owners see **Require two-factor authentication** here, and owners and administrators can reset a second factor for someone who has lost their phone and codes — never for themselves. Both are described on [Two-factor authentication](/en/security/two-factor).