Roles & Permissions

Lumio uses role-based access control (RBAC) to decide exactly what every team member can see and do inside your account. Roles are account-scoped: the same user can be a Moderator on your channel and an Owner on a friend's channel, and Lumio tracks that separately.

Who needs this guide?

• Account owners setting up a team for the first time.
• Administrators who need to create custom roles (for example, an "Editor" that can manage overlays but not chat).
• Members who want to understand why a page or button is hidden for them.
• Popout-token users configuring OBS browser-source docks with the right permissions.

Where to Find It

• Roles live under Manage → Roles (/dashboard/roles). You need roles:read to see the page and roles:edit / roles:delete to modify roles.
• Members live under Manage → Members (/dashboard/members). You need members:read to see the list and members:edit to change someone's role.
• Your own permissions are reflected everywhere — buttons, nav items, and entire pages simply disappear when you lack a permission, and protected pages show a "No Access" state with the message "Contact the account owner to get access."

Quick Start

1. The account creator is always the Owner — they start with every permission.
2. Three other default roles exist for every new account: Administrator, Moderator, Viewer.
3. To bring someone onto your team:
   • Open Manage → Members, click Invite.
   • Choose a method: Invite Link, Invite Token, or Invite Person (search by username/email/platform).
   • Pick a role (the Owner role cannot be assigned this way — it's reserved for the account creator).
   • Configure validity (1 hour, 24 hours, 7 days, 30 days, or Never) and max uses.
   • Share the link or token.
4. If the four default roles don't fit, create a custom role under Manage → Roles → Create Role and pick exactly the permissions it needs.

How It Works

Every action in Lumio — sending a chat message, saving an overlay, creating an invite — is guarded by a permission string in the form resource:action (for example chat:ban, overlays:edit). Wildcards like * or chat:* are not supported; permissions are always granular.

When a user performs an action, Lumio looks up the roles assigned to them on the current account, unions their permissions, and checks whether the required string is present.

• The backend enforces permissions on every GraphQL resolver and REST handler, so switching protocols can't bypass a guard.
• The frontend uses the same permission list to hide nav items, dim disabled buttons, and render graceful "No Access" pages instead of raw 403 errors.
• Permissions are cached in Redis per user + account for performance. The cache is automatically invalidated whenever a role's permissions change, a member is added/removed, or a role is reassigned, so changes take effect within seconds.

Role anatomy

Every role has:

Field	Purpose
name	Human-readable label shown in the UI (e.g. "Moderator", "Content Editor").
slug	Machine identifier auto-generated from the name (e.g. content-editor). Used for translations and API calls.
description	Free-text hint shown in the role list.
color	Hex color used in the member list badge.
is_system	If true, the role is protected: it can't be deleted and, for Owner, can't be edited.
permissions	The list of resource:action strings granted by this role.

Default Roles

Lumio seeds four roles into every new account. All slugs are stable and match those checked by the backend.

Owner (owner)

• is_system: true — cannot be deleted and is the only role that cannot be revoked from the account creator.
• Holds every account permission including account:delete (dissolve the account) and plan:edit (change billing).
• Automatically assigned to whoever created the account; ownership can be transferred via the settings page, but the role itself always exists.

Administrator (administrator)

• Same broad access as Owner, minus account:delete, plan:read, plan:edit and extension-dev:payouts.
• Can manage team, overlays, chat, automations, connections, etc. — essentially everything a co-streamer or production lead needs.
• Can be edited (it is not a system role), but like every seeded default role it has no delete button.

Moderator (moderator)

• Built for chat mods: chat:read, chat:write, chat:userinfo, chat:delete, chat:ban, chat:timeout, chat:notes, chat:raid, chat:poll, chat:prediction, chat:refresh_user.
• Events: events:read, events:create (fire test events), events:userinfo.
• Read access to overlays, connections, uploads, rewards, widgets, sounds, bot-modules, bot-commands, bot-connections, and the OBS config (obs:read).
• Spotify: read + playback + queue + playlist + device (no volume, no worker start/stop).
• Automations: read + execute + history (cannot create or edit).
• Members/roles: read-only (members:read, roles:read) — mods can see the team but not change it.
• Sessions: can view and revoke their own active sessions.
• Copyright: the viewer-style actions only — copyright:vote, copyright:report, copyright:recommend.
• Extensions: extension-store:read, extension-store:review, extension-data:read.
• Sounds: sounds:read + sounds:play.
• Stream History: history:read + history:export.
• Public Stats: public-stats:read (view publicness settings; cannot change them).

Viewer (viewer)

• Read-only dashboard. Useful for a silent observer (a manager, an analytics seat, a backup account).
• Holds events:read, events:userinfo, overlays:read, bot-commands:read, widgets:read, sounds:read, extension-store:read, extension-store:review, extension-data:read, and session view/revoke.
• Cannot chat, cannot touch automations, cannot see members, roles or settings.

Custom Roles

If the defaults don't fit — the most common case is "I want a role that can do X but not Y" — create a custom role.

1. Open Manage → Roles, click Create Role.
2. Step 1 — Role Details: enter a name, an optional description ("What can this role do?"), and pick a color. The slug is auto-derived.
3. Step 2 — Permissions: check exactly the permissions you want. They are grouped by category (Events, Overlays, Spotify, Chat, …). The UI shows a running count at the bottom: "N permissions selected".
4. Step 3 — Summary: review and click Create Role.

Editing works the same way — click the pencil icon on the role card and the three-step wizard reopens with the current values; in edit mode you can jump to any step and save from there. The Owner role shows a System badge and has no pencil icon. None of the four seeded default roles show a delete icon — only custom roles you create can be deleted.

To assign a custom role: go to Manage → Members, find the member, and change their role from the Role column. You need members:edit to do this.

Permission Categories

Permissions are grouped into categories that double as UI section headers in the role editor. Below are the categories and the resource:action strings inside each.

Granular pattern

Almost every category follows the same shape:

• resource:read — see the data.
• resource:create — make new entries.
• resource:edit — modify existing entries.
• resource:delete — remove entries.

One historical exception uses :write instead of granular create/edit/delete:

• chat:write — permission to send chat messages. (Deleting chat messages is separate: chat:delete.)

Everywhere else, stick to the granular triple.

Events

• events:read — view the events feed and history.
• events:create — emit test events.
• events:userinfo — open the user card from an event row.

Overlays

• overlays:read, overlays:create, overlays:edit, overlays:delete.
• overlays:access-read — read per-overlay access entries/candidates and see all overlays (access-manager visibility; Owner and Administrator only).
• overlays:access-grant — grant (set) per-overlay access for a user (Owner and Administrator only).
• overlays:access-revoke — revoke per-overlay access for a user (Owner and Administrator only).

Widgets

• widgets:read, widgets:create, widgets:edit, widgets:delete — standard widget instance CRUD.
• widgets:access-read — read per-widget access entries/candidates and bypass per-widget restrictions (Owner and Administrator only).
• widgets:access-grant — grant (set) per-widget access for a user (Owner and Administrator only).
• widgets:access-revoke — revoke per-widget access for a user (Owner and Administrator only).

Sounds

• sounds:read, sounds:create (upload), sounds:edit, sounds:delete — the sound library used by alerts and automations.
• sounds:play — trigger playback of a sound. Moderators get sounds:read + sounds:play; Viewers only sounds:read.

Extension Store

• extension-store:read — browse the store and the Installed list (Owner, Administrator, Moderator, Viewer).
• extension-store:install, extension-store:uninstall, extension-store:configure — install, remove and configure extensions on this account (Owner and Administrator only).
• extension-store:review — write a store review for an extension.

Extension Developer

• extension-dev:read — open the developer dashboard.
• extension-dev:create, extension-dev:edit, extension-dev:delete — manage your own extensions.
• extension-dev:publish — submit and publish versions.
• extension-dev:analytics — see install and usage analytics for your extensions.
• extension-dev:payouts — manage payout details and request payouts (Owner only).

These only matter once your user has been approved as a developer — see Developer Application & Team Roles.

Extension Data

• extension-data:read — read data from an installed extension's server query functions (Owner, Administrator, Moderator, Viewer).
• extension-data:edit — insert / patch / delete data through an installed extension's server functions (Owner and Administrator only).
• These gate only direct calls from the dashboard editor or the lumio run CLI. Widgets running in a Browser Source use the extension install's own scope and are unaffected.

Stream History

• history:read — view the session list, reports and time-series stats (Owner, Administrator, Moderator).
• history:export — export reports as CSV / PDF / TXT / JSON (Owner, Administrator, Moderator).
• history:share — create, extend and revoke shareable report links (Owner and Administrator only).
• history:delete — delete stored sessions (Owner and Administrator only).
• All four are gated behind the Stream History feature (available on the Free and Pro plans).

Public Stats

• public-stats:read — view your channels' publicness settings for the public Stats app (Owner, Administrator, Moderator).
• public-stats:edit — toggle a channel's publicness (opt out / opt back in) and hide or show its chatter leaderboard (Owner and Administrator only).
• Both are gated behind the Public Stats feature (available on the Free and Pro plans). Publicness is public-by-default: a channel is listed until its broadcaster opts out.

Crawler

Platform-operator controls for the public stats crawler, exposed in the Admin app (and gated on admin:access to reach it). These are admin-scope permissions (ZAF-725), assigned via admin roles (seeded to system_admin) — they are not account role permissions, so no account owner/administrator/moderator/viewer holds them.

• crawler:scope-read / crawler:scope-edit — read and set which live channels the crawler covers (lumio, list, lumio_plus_list, or the opt-in global sweep). The default is the bounded lumio_plus_list.
• crawler:watchlist-read / crawler:watchlist-create / crawler:watchlist-delete — view and curate the crawl watchlist (the list component of the scope).

Each scope change or watchlist edit is recorded in the operator audit log.

Audit Log

• audit-log:read — view this account's Audit Log: role and permission changes, member-role assignments, channel connections, and account-scoped GDPR erasures (Owner, Administrator). This account-scope permission is separate from the Lumio-internal admin audit log, which uses a same-named admin permission. It is not needed for Account → My Activity, which is self-only for every signed-in user.

Spotify

• spotify:read — now playing, queue, devices, playlists, search.
• spotify:playback — play / pause / skip / shuffle / repeat.
• spotify:volume — change playback volume (hides the volume slider when missing).
• spotify:queue — add tracks to the queue.
• spotify:playlist — create / rename / delete playlists, manage tracks.
• spotify:device — transfer playback between devices.
• spotify:worker — start / stop the manual Spotify connect worker.

Chat

• chat:read, chat:write, chat:userinfo, chat:delete, chat:ban, chat:timeout, chat:notes, chat:raid, chat:poll, chat:prediction, chat:refresh_user.
• chat:refresh_user — manually refresh a user's platform profile (avatar, bio, follow status) from the UserInfoModal. Rate-limited to once per 10 minutes per user. Available to Owner, Administrator, and Moderator.
• chat:userinfo also controls whether the \{\{username\}\}, \{\{displayName\}\}, \{\{avatarUrl\}\}, and \{\{userId\}\} automation template variables resolve (see Automation Templates).

Connections

• connections:read, connections:create, connections:edit, connections:delete — for Twitch/YouTube/Kick/Trovo channel connections, Discord, Spotify, StreamElements, etc.

Settings

• settings:read, settings:edit.

Members

• members:read — see the members and invites tabs.
• members:create — create invite links / tokens / direct invites, search users.
• members:edit — change someone's role.
• members:delete — remove a member or revoke an invite.

Roles

• roles:read, roles:edit, roles:delete.

Uploads

• uploads:read, uploads:create, uploads:delete. Plan limits apply on top — see Billing & Subscription for the current per-file and total storage limits.

Rewards

• rewards:read, rewards:create, rewards:edit, rewards:delete — channel-point rewards and their handlers.

Tokens

• tokens:read, tokens:create, tokens:delete — view, create, and revoke popout tokens (OBS browser-source docks). Managed under the feature:tokens feature gate.
• tokens:edit — edit popout token labels, expiry, user assignment, and permissions.

API Keys

Both personal user API keys (lm_usr_…) and account service keys (lm_svc_…) share one dedicated permission family, separate from popout tokens. The Dashboard → API Keys page uses these permissions plus the feature:apikeys feature gate — see API Keys for the personal-vs-service distinction.

• apikeys:read — view API keys.
• apikeys:create — create a new key (scoped within your own permissions — a key can never exceed what its creator holds).
• apikeys:edit — rename a key. The key material, permissions, and expiry are immutable once minted; only the display name can change.
• apikeys:delete — revoke a key.

Service keys introduce no new permission — they reuse the same apikeys:{read,create,edit,delete} family. The one behavioural difference is ownership: a service key belongs to the account and keeps working after the member who created it leaves, whereas a personal key stops the moment its owner is no longer a member.

Automations

• automations:read, automations:create, automations:edit, automations:delete — standard automation CRUD. automations:edit also covers renaming, toggling enabled, and modifying nodes/edges.
• automations:execute — manually trigger and start/stop automations.

Account & Plan

• account:read, account:edit, account:delete (dissolve the whole account — Owner only by default).
• plan:read, plan:edit (subscription / billing — Owner only by default).

Sessions

Session management is not an account-role permission. Every authenticated user can view and revoke their own active browser sessions regardless of account role, and regardless of whether an account is selected in the account switcher at all. The former sessions:read / sessions:delete role permissions were removed in ZAF-1094 — they gated nothing.

OBS

• obs:read, obs:edit, obs:delete — the OBS WebSocket remote-control configuration.

Copyright

• copyright:read, copyright:edit, copyright:delete — this account's own copyright review lists.
• copyright:vote, copyright:report, copyright:recommend — viewer-style actions (moderators get these but not edit/delete).
• copyright:moderate — approve/dismiss community vote candidates into the global cross-account blocked/safe catalogue. This is a platform-operator (admin) permission, not an account-role permission: it is held only by platform staff via the admin (system_admin) role, never by a tenant Owner or Administrator. It was moved out of account scope in ZAF-742 because it writes the shared global catalogue, not your own account's lists (which copyright:edit covers).

Bot Modules / Bot Commands / Bot Connections / SE Tokens

• bot-modules:read, bot-modules:edit — link protection, spam, word filter, timed messages.
• bot-commands:read, bot-commands:create, bot-commands:edit, bot-commands:delete.
• bot-connections:read, bot-connections:create, bot-connections:delete — custom bot identities.
• se-tokens:read, se-tokens:create, se-tokens:delete — StreamElements tip-jar tokens.

Login Assignments (User-Level)

Permission	Description
login-assignments:read	View which login connections are assigned to the account (all users)
login-assignments:create	Assign login connections for any user on the account
login-assignments:delete	Remove login connection assignments for any user

Every user can always manage their own login assignments without these permissions. The permissions above are user-level and control access to other users' assignments on the same account.

Developer Application & Team Roles

Becoming a developer on Lumio requires an application. The developer application flow and team roles use a separate permission layer from account roles.

Becoming a Developer

1. Navigate to Account > Developer (/account/developer).
2. Fill out the application wizard: choose Solo or Team, provide a display name, URL slug, description, motivation, and what you plan to build.
3. Submit the application for review.
4. A Lumio admin reviews the application and approves or rejects it with notes.
5. On approval, a developer profile is created. For team applications, a team is also created with default roles.

The me query exposes an isDeveloper boolean field that is true when the user has a developer profile or has the admin extension_dev_mode override. This field controls access to the developer dashboard.

Developer Team Roles

Developer teams use their own RBAC system, separate from account roles. Each team has custom roles with granular team-* permissions covering extensions, versions, secrets, testers, members, settings, and payouts.

Three default roles are seeded for every new team:

Role	Description
Owner	Full team access. System role, cannot be deleted.
Admin	Manage extensions and members. Cannot edit team settings, payouts, or remove members.
Member	View and develop extensions. Read-only access to team settings and members.

Custom team roles can be created through the team settings page. The team role editor works the same way as the account role editor: pick a name, description, and a set of team-* permissions.

Notifications

The developer lifecycle includes email and in-app notifications for:

• Application submitted, approved, or rejected
• Extension created, version submitted/approved/rejected/published, extension suspended
• Access granted or revoked, tester invited/removed, tester feedback
• Team invite sent/accepted, team member removed, team role changed

Concrete Recipes

"A mod who can ban but not touch overlays"

The default Moderator already does this — they have chat:ban + chat:timeout + chat:delete, and only overlays:read. If you want to also block overlay viewing, create a custom role with the Moderator's permissions minus overlays:read.

"A content editor who designs overlays but should never moderate chat"

Create Content Editor with:

• overlays:read, overlays:create, overlays:edit, overlays:delete
• uploads:read, uploads:create, uploads:delete
• rewards:read, rewards:edit
• events:read, events:userinfo
• settings:read (to see OBS URLs)
• tokens:read, tokens:create (so they can create popout tokens for preview docks)

Leave chat, automations, connections, members, roles untouched.

"A stats-only seat for an agency / manager"

Assign Viewer as-is, or build a custom role from the Viewer permission set plus chat:read + chat:userinfo if they need to read chat for context. Do not grant chat:write.

"A co-host who can run the whole stream except billing"

That's exactly Administrator. Assign it as-is.

"A VA who triggers automations but can't change them"

Start from Moderator; ensure automations:read + automations:execute are on (Moderator already has both by default); leave automations:create, automations:edit, and automations:delete off. Optionally remove chat moderation if they shouldn't ban/timeout.

Popout Tokens

When you create a popout token under Manage → Tokens, you choose a subset of permissions for that token. The token can never have more permissions than the creator's role — Lumio intersects the two lists on save.

A Moderator creating a popout token for OBS can therefore never produce a token with settings:edit or automations:edit, even by editing the request manually.

Permissions Cheat-Sheet

Capability	Permission
Read chat	chat:read
Send chat messages	chat:write
Timeout users	chat:timeout
Ban users	chat:ban
Create overlays	overlays:create
Edit overlays	overlays:edit
Create / duplicate widgets	widgets:create
Edit widget config	widgets:edit
Read widget access	widgets:access-read
Grant widget access	widgets:access-grant
Revoke widget access	widgets:access-revoke
Upload files	uploads:create
Connect Twitch/YouTube/etc.	connections:create
Invite members	members:create
Change member roles	members:edit
Create custom roles	roles:edit
Create automations	automations:create
Edit automations (nodes, edges, enabled)	automations:edit
Delete automations	automations:delete
Run automations manually	automations:execute
Create popout tokens	tokens:create
Create personal API keys	apikeys:create
Change plan / billing	plan:edit
Dissolve account	account:delete
View account audit log	audit-log:read
View your own activity log	none — signed-in user only

Lumio Internal: Privacy Tooling

admin:privacy-erase is a Lumio-internal admin-scope permission used by support staff to honour GDPR Art-17 erasure requests for cached data (currently: YouTube member-channel records). It is not assigned to per-account roles like Owner/Administrator/Moderator/Viewer — only the system_admin Lumio admin role carries it. End users do not see this permission in the role editor. Erasures are audit-logged.

csp-reports:read is likewise a Lumio-internal admin-scope permission. It lets platform staff read the CSP-violation calibration aggregate (which browser Content-Security-Policy rules would have blocked, and on which host) so the policy can be tightened safely. It stores only the violated directive and the scheme+host of the blocked resource — no page URL, no viewer identity — and is not assigned to per-account roles; only the system_admin Lumio admin role carries it. End users do not see it in the role editor.

Ideas Hub Roles

The sections above describe account-scoped roles — they control what you can do within a specific account (overlays, chat, music, automations, etc.). The Ideas Hub uses a separate permission layer: user-scoped roles. These roles are tied to your user identity across Lumio, not to any single account.

Why a separate layer?

Account roles answer "What can this person do on my channel?" User roles answer "What can this person do in cross-account features like the Ideas Hub?" The two layers are independent: an Owner on their own account still has whatever user role they hold when they visit the Ideas Hub, and a Restricted user in the Ideas Hub can still be an Administrator on someone else's account.

Default User Roles

Lumio assigns one of three user roles to every user. All new users start as Member.

Member

The default role. Members have full access to the Ideas Hub:

• Create new ideas
• Edit and delete their own ideas
• Vote on ideas
• Read and create comments
• Vote on comments and replies
• Edit and delete their own comments

Restricted

Read-only access. Restricted users can browse ideas and read comments but cannot contribute content or vote. This role is assigned by Lumio moderators to users who have violated community guidelines.

Moderator

Everything a Member can do, plus moderation capabilities across the entire Ideas Hub:

• Review and change the status of any idea (e.g. mark as planned, completed, or declined)
• Edit or delete any idea, regardless of author
• Delete any comment, regardless of author (editing a comment is always author-only)

Permissions by Role

Action	Member	Restricted	Moderator
Browse ideas	Yes	Yes	Yes
Create ideas	Yes	No	Yes
Edit own ideas	Yes	No	Yes
Delete own ideas	Yes	No	Yes
Vote on ideas	Yes	No	Yes
Read comments	Yes	Yes	Yes
Create comments	Yes	No	Yes
Vote on comments	Yes	No	Yes
Edit own comments	Yes	No	Yes
Delete own comments	Yes	No	Yes
Moderate all ideas	No	No	Yes
Change idea status	No	No	Yes

Tips & Best Practices

• Prefer custom roles over editing the defaults. If you change the Moderator role, every mod on the account changes with it. A custom "Chat Mod (no polls)" role keeps the default intact.
• Start restrictive. It's easier to add permissions on request than to explain a security incident.
• Name roles by function, not by person. "Content Editor" ages better than "Sarah".
• Use the color field. Member badges use it — green-for-mods, blue-for-editors is much faster to scan than reading labels.
• Invite tokens for manual distribution, invite links for DMs. Invite links include the role; the recipient clicks and lands on a "You have been invited" page. Tokens are paste-into-dashboard for people already signed in.
• Sessions matter. Every user manages their own sessions under Account → Sessions; if a collaborator's laptop is lost, have them revoke their sessions there before you change their role — otherwise their existing browser tab keeps the cached permissions until the next refresh.

Troubleshooting

"Why can't I see the Music page?"

Your role lacks spotify:read (and usually also spotify:playback). Ask the Owner to add the Spotify permissions — the entire Music nav item is hidden when spotify:read is missing.

"I see 'No Access — Contact the account owner to get access.'"

You navigated to a URL (maybe from a bookmark) for a feature you don't have permission to use. The message is a deliberate friendly 403; check your role under Manage → Roles.

"I edited the role but the member still can't do the thing."

The permission cache refreshes when the role is saved, but the member's browser may need a reload to pick up the new hidden/visible UI. Ask them to refresh. If it still fails, verify the permission string is really on the role (open the role, check the Permissions step).

"The Owner role is greyed out — I can't edit it."

Correct. Owner is a system role (is_system: true). It always has every permission and cannot be modified or deleted. If you need a "near-Owner" role, edit or clone Administrator instead.

"I can't assign the Owner role when inviting."

By design. The invite wizard hides Owner ("Owner role cannot be assigned"). Ownership transfers go through account settings, not invites.

"Can a member belong to multiple roles?"

Currently no: each member has exactly one role per account. To give someone a superset of permissions, create a custom role combining the two.

"How do I give a popout token fewer permissions than my role?"

Create the token under Manage → Tokens → New Token, and uncheck permissions you don't want on it. The list is pre-filled with your current permissions as the upper bound.

Related Docs

• Automation Templates — which permissions gate which template variables.
• Account Switching — how roles work across multiple accounts you belong to.
• Popout Tokens — permission-bounded tokens for browser sources.