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 Settings → Channel → Roles (/dashboard/settings/channel/roles). You need roles:read to see the area and roles:edit / roles:delete to modify roles.
• Members live under Settings → Channel → Members (/dashboard/settings/channel/members). You need members:read to see the area 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. Two other default roles exist for every new account: Administrator and Moderator.
3. To bring someone onto your team:
   • Open Settings → Channel → 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 three default roles don't fit, create a custom role under Settings → Channel → 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 three roles into every new account. All slugs are stable and match those checked by the backend. Accounts created earlier may have a fourth role named viewer: unused ones were deleted, while those with a member or a redeemable invite became ordinary custom roles with unchanged permissions.

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:pin, chat:poll, chat:prediction, chat:refresh_user, chat:automod-read, chat:automod-allow, chat:automod-deny.
• 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, account chat bots, 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.
• Setting Presets: presets:share (may share their own presets with the account).
• Public Stats: public-stats:read (view publicness settings; cannot change them).

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 Settings → Channel → 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 three seeded default roles show a delete icon - only custom roles you create can be deleted.

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

Permission Categories

Platform operators can be granted the admin-scope support:verify permission to view and check a user's hourly support code in the Admin app. It does not belong to a channel role. Resetting a user's 2FA is a different operator action guarded by admin users:edit and requires a reason.

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:edit - hide the buyer name of a Shopify order in the events feed. Owner and Administrator have it by default.
• 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 see all widgets, including ones set to none for you (access-manager visibility; it does not grant editing; 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.

Extension Store

• extension-store:read - browse the store and the Installed list (Owner, Administrator, Moderator).
• 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).
• 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, and the current Sub count of each connected channel (Owner, Administrator, Moderator).
• history:export - export filtered lists and finalized 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).
• history:revenue-read - read estimated revenue and assumptions and include revenue in shared reports (Owner and Administrator only).
• history:revenue-edit - edit revenue assumptions (Owner and Administrator only).
• history:keywords-edit - add, change and remove tracked keywords (Owner and Administrator only). history:read also permits listing keywords and testing a pattern.
• All seven are gated behind the Stream History feature (available on the Free and Pro plans).

Setting Presets

• presets:share - share one of your own setting presets with the members of your active account, so the team can load ("use") it (Owner, Administrator, Moderator).
• Only sharing is gated: creating, editing and loading presets is per-user and needs no permission, and reading the shared section needs only account membership.
• Gated behind the Setting Presets feature. When you share a preset, every member of the account can see and load it - the confirmation says so.

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 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:pin, chat:poll, chat:prediction, chat:refresh_user, chat:automod-read, chat:automod-allow, chat:automod-deny.
• chat:automod-read shows held Twitch messages in Multichat. The AutoMod tab in Stream History additionally requires history:read; allow and deny have their own permissions and use your Twitch sign-in. A popout token can carry the three live AutoMod permissions, but cannot open the history log.
• 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 channel connections, Discord, Spotify, StreamElements, the Shopify store, etc. connections:edit changes the Shopify customer label. connections:read also controls the dashboard's channel status and the channelStatus / GET /v1/channel-status reads; spotify:read controls Spotify music and manual status separately.

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 Settings → Channel → Access → 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 or rotate its secret. The scopes and expiry are immutable once minted; you can change the display name and regenerate (rotate) the secret in place. Rotation returns the new full key once and invalidates the old secret immediately.
• 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.

Operator management (support). Lumio platform operators and support staff can view, edit (label + scopes), rotate, and revoke any account's or user's API keys from the admin app, under the separate admin-scope account-apikeys:{read,edit,rotate,delete} family (never assignable to a tenant role). This is distinct from the account-scope apikeys:* above - an operator editing a key can never push it above the key's own principal (a personal key stays capped to its owner's permissions). See Admin → API Keys.

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 (the channel name and picture: source, own name, own picture), 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.
• chat-bots:read - see the channel bot list and automatically recognised bots (Owner, Administrator, Moderator).
• chat-bots:edit - mark and unmark platform accounts as bots (Owner and Administrator). See Channel settings → Bots.
• 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 (/dashboard/settings/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	Edit extensions, create and upload versions, and view analytics. Cannot submit a version, delete an extension, or manage or list testers and private access.

For team-owned extensions, the role controls each action after Lumio confirms you belong to the owning team. A missing grant returns Missing team permission: <permission>; role changes take effect on your next request. A solo extension has no team-role check. The Owner and Admin roles can submit versions and manage testers; a custom role can grant those actions selectively.

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"

Create a custom role with only the read permissions this person needs, such as events:read, events:userinfo and overlays:read. Add chat:read + chat:userinfo if they need chat 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 Settings → Channel → Access → Popout 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
Pin, change the duration or unpin a Twitch message	chat:pin
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 (duplicating also needs Editor access to the source widget)
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 (currently: YouTube member-channel records, chat-subject data, a person's entries on Lumio's own surfaces, and orphaned extension upload files). A chat-subject or member erasure acts in one channel only, on that channel's instruction; the Lumio-only erasure touches no channel's data. It is not assigned to per-account roles like Owner/Administrator/Moderator - only the system_admin Lumio admin role carries it. End users do not see this permission in the role editor. Erasures are audit-logged.

admin:privacy-objection-create and admin:privacy-objection-delete are Lumio-internal admin-scope permissions of the same kind. Support staff use them to record or lift a chatter's GDPR Art-21 objection: afterwards, public Stats leaderboards hide the name, also on streams published earlier, without erasing anything. A channel's own stream reports, share links and AutoMod log are not affected. Only the system_admin Lumio admin role carries them; end users do not see them in the role editor. Both actions are audit-logged.

admin:privacy-erase-withdraw is another Lumio-internal admin-scope permission. Support staff use it when a channel withdraws its instruction to erase a chat participant: that channel's stream reports created afterwards show the participant's name again. Nothing the erasure deleted comes back, and other channels are not affected. Only the system_admin Lumio admin role carries it; end users do not see it in the role editor. The withdrawal is 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.

Withdrawal and cancellation permissions

A signed-in member needs plan:edit to submit a withdrawal or cancellation for a plan and extension-store:uninstall for a paid extension purchase or subscription. The public /withdraw and /cancel forms require no account role. A signed-in Other contract withdrawal needs an interactive session. Withdrawal & Cancellation explains the forms.

The operator queue uses admin-scoped contract-declarations:read to view cases and contract-declarations:edit to match, close or extend them. These grants do not appear in account role pickers and are assigned to system_admin by default.

developer-funds:release-deletion is a Lumio-internal admin-scope permission. Support staff use it, on a developer's request, to delete a developer profile whose balance cannot be paid out (no payout method or no verified identity); Lumio keeps the balance as a claim and mails the person a claim code. It is assigned to system_admin by default and does not appear in account role pickers.

developer-funds:settle is the matching admin-scope permission for when that person comes back with the claim code: support staff record the claim and credit the kept balance to the person's new, verified developer profile, from where the normal payout pays it out. It is assigned to system_admin by default and does not appear in account role pickers.

extension-purchases:read is likewise a Lumio-internal admin-scope permission. Support staff use it to find paid extension checkouts that were never delivered (for example, an automatic refund that Stripe refused), so they can refund the buyer or install the extension. It 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.

devtools:read is likewise a Lumio-internal admin-scope permission. It shows the Dev & Admin menu in the web app to Lumio staff (for example, to preview a seasonal look in their own browser). It is not assigned to per-account roles; the system_admin Lumio admin role carries it, and Lumio can grant it to further internal admin roles. 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 Settings → Channel → 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 Settings → Channel → Access → Popout 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.