# Users & Permissions > Add team members and control what each of them can see and do, per broadcast channel, using roles, presets, and per-permission grants. Source: https://sendbroadcast.net/docs/users-and-permissions Broadcast is built for teams where not everyone should be able to do everything. A freelance writer might need to draft broadcasts on one newsletter but never send them. An analyst might need to read performance numbers across every channel without being able to change anything. Permissions are how you say so. Access is controlled at two levels: - **System permissions** apply to the installation as a whole: managing users, creating channels, changing system settings, and other administrative work. - **Channel permissions** apply per [broadcast channel](https://sendbroadcast.net/docs/channels). A user can be an Editor on one channel, a Viewer on another, and have no access at all to a third. Everything described here lives under **User Management** in the sidebar. Note **Automating this?** Everything on this page except sudo access can also be done with an admin API token through the [Users API](https://sendbroadcast.net/docs/api-users), or the Users resource in each [SDKs & Client Libraries](https://sendbroadcast.net/docs/sdks) client. ## The users list The users page lists everyone with an account: name, email, status, and an access summary such as "Editor · 12 channels". You can search by email, first name, last name, or full name, and the sidebar offers quick filters for common questions: sudo users, non-sudo users, users with read-only access, users who have not signed in for 30 days, and users active in the past week. From a user's page you can edit their account details, activate or deactivate the account, and manage both kinds of permissions. Deactivated users cannot sign in; their permission records are kept, so reactivating restores their access exactly as it was. ## Sudo access A sudo user bypasses every permission check: all channels, all settings, everything. The first account created on an installation is typically a sudo user, and most installations need very few of them. Sudo can be granted in two places, and either one is sufficient: the **Sudo** checkbox on the Edit User form, or **Sudo access** under Dangerous Operations on the user's System Permissions page. To revoke it, turn it off in whichever place granted it. The System Permissions page stays reachable for sudo users for exactly this reason. Warning Grant sudo sparingly. A sudo user can read and export every subscriber list, change email server credentials, and manage other users, including promoting anyone else to sudo. For day-to-day administration, a targeted set of system permissions is almost always enough. ## System permissions A user's System Permissions page grants installation-wide capabilities individually: | Permission | What it allows | |---|---| | User Management | Create, edit, and manage user accounts and their permissions | | Channel Management | Create and manage broadcast channels | | System Settings | Modify system-wide settings and configuration | | System Monitoring | Access monitoring and performance data | | System Backups | Create and restore backups | | System Updates | Install updates and manage software | | Billing Management | Access billing and subscription management | Sudo access also lives on this page, under **Dangerous Operations**, alongside backups and updates. Quick presets (No Access, Basic Admin, Full Admin) fill the checkboxes for the common cases. ## Channel permissions Each user's **Channel Permissions** page shows one row per channel they can access, with a role badge and a plain-language summary of what that role can do. Expand a row to see the full breakdown: every granted permission, grouped by area (Subscribers, Broadcasts, Sequences, Templates, and so on), with anything not granted summarised underneath. Channels the user cannot access are listed separately in a **No access** table. Use **Grant access** on any of those rows to give them their first permissions on that channel. Both tables are searchable by channel name. ### Roles A role badge is not stored anywhere: Broadcast computes it by comparing the user's actual permissions on that channel against the built-in roles. If the permissions match a role exactly, the badge shows it. If they match one of your saved presets, the badge shows the preset's name. Anything else shows as **Custom**, with a description of how it differs from the nearest role, for example "Full access except Autopilot". | Role | What it can do | |---|---| | Viewer | Read-only: view subscribers, broadcasts, sequences, templates, segments, forms, and their performance | | Editor | Everything a Viewer can, plus create, edit, send, and manage content and files | | Manager | Every permission on the channel, including settings, email servers, API tokens, and suppression lists | Individual permissions follow a hierarchy: granting a write permission automatically grants the matching read permission, so a permission set can never say "may edit broadcasts but may not see them". ### Applying permissions to many channels at once For a user who needs the same access across many channels, select the channels with the checkboxes on their Channel Permissions page, choose a role or preset from the **Apply** control that appears, and confirm. One submit stamps the same permissions onto every selected channel. Warning Applying a role or preset **replaces** the selected channels’ current permissions for that user. It does not add to them. The confirmation step is there because there is no undo; to restore the old access you would set it again by hand. The same bulk option exists on the grant form itself: when granting access to a new channel, you can select additional channels and create all the permission records in one go. ## Permission presets A preset is a named, reusable permission set, managed under **Permission Presets** on the Channel Permissions page. Give each preset a short description of who it is for ("Creates and sends campaigns; no settings access"); the description is shown wherever the preset appears, so other admins can pick the right one without opening it. You can create a preset from scratch, or save the current selection as a preset while editing any user's permissions. Note Presets are **copied at the moment you apply them**, not linked. Editing a preset later changes what future applications will grant; it does not change any user who already received it. A user whose permissions were set from a preset keeps showing that preset’s name on their badge only for as long as their permissions still match it exactly.