Members and roles

Members are the people who can sign in to an organization. Roles decide what each member can do.

The model is small on purpose: invite a member, assign a role, group members when permissions repeat, review the access list when work changes.

The members table

Open Organization settings → Organization to see the members table. Each row is one member.

Owners and admins can act on every row except their own destructive actions. The current operator cannot remove themselves until ownership is transferred.

Invitations

Open the Invite Members dialog from the members card or the pending invitations card.

The dialog has two paths. Both can be used in one organization.

By email

The invitation enforces role hierarchy. An admin cannot invite an owner. A member cannot invite anyone unless the role is below their own. The dropdown only lists roles the current operator can target.

When an invite is sent, the recipient gets an email with a sign-in link. Until they accept, the invite shows in the Pending Invitations card.

By magic link

A magic link grants the chosen role to whoever has the link. Use it for short-lived shares (a launch sprint, a partner workshop, a procurement contact). Regenerate the link if the role or expiry changes.

Pending invitations

Pending invitations live in their own card under the members table. Each row supports:

• Resend. Sends the original email again.
• Cancel. Revokes the invitation. The recipient can no longer accept.

A pending invitation does not consume a seat until the member joins.

Built-in roles

Every organization ships with the same default roles. Custom roles can be added on top.

There is exactly one Primary Owner per organization. The primary owner can transfer ownership but cannot leave the organization without transferring first.

What each role can do, by default

The matrix above is the starting point. Permissions can be customized per role and per organization on the Permissions page. Customized cells are highlighted in the matrix.

Custom roles

Open Organization settings → Organization → Roles to manage custom roles.

Custom roles let an organization define its own permission shape. Use them when the built-in roles are close but not exact (an "Editor" with no delete rights, a "Reviewer" with approval but no draft rights).

Roles enforce hierarchy. A custom role above "member" cannot be assigned by a member. A custom role below "admin" can be assigned by any admin.

Deleting a custom role moves every member with that role back to the next role below in the hierarchy. The roles table shows usage count before deletion.

Access groups

Access groups make repeated permission changes easier. A group is a named bundle of members plus a permission matrix attached to the group.

Open Organization settings → Organization → Access Groups to manage them.

When to use a group

Do not create an access group for one person. Assign that member directly.

What a group contains

Access group permissions cover content resources only. The following are managed at the role or organization level and are excluded from groups:

• Roles
• Settings
• Access groups
• Analytics
• Audit log
• SSO and SCIM
• API keys
• OAuth clients
• MCP

A group can grant read on brand, campaign, project, template, and similar work resources. It cannot grant access to organization-level controls.

Transfer ownership

Ownership transfer moves primary control to another member. Open the member's row → Transfer ownership to start.

Before transferring:

1. Confirm the new owner can pass identity and billing checks.
2. Confirm the new owner is set up as a billing operator if billing should follow.
3. Decide whether the previous owner should keep an admin role or leave the organization.

After transferring, review:

• Owner list. There must always be at least one primary owner.
• Billing contact. The plan and payment method follow the organization, not the previous owner.
• SSO and authorized apps. Verify access still works for the new owner.
• Pending invitations. Cancel and reissue any that named the previous owner.
• API keys. Rotate keys owned by the previous owner.

Remove a member

Removing a member ends organization access immediately. Audit records keep the original member name attached to past actions.

Removal checklist

Before removing a member, check whether they own active work:

• Open approvals waiting on them in Brand Guard.
• Drafts assigned to them in Strategy Studio, Content Engine, or Creative Lab.
• API keys created under their name.
• MCP connections configured by them with personal scope.
• Scheduled tasks or automations they configured.
• Integrations connected with their credentials.

Reassign or revoke the items above before removing the member. The system will surface blocking items where possible, but ownership of work is an organizational decision.

What survives removal

Read next

• Settings. Organization profile, notifications, activity, permissions, danger zone.
• Security and integrations. SSO, SCIM, role mapping, authorized apps.
• Billing and usage. Seats, plan limits, BYOK, overage.