Set admin roles
Set admin roles
Role-Based Access Control
With Role-Based Access Control (RBAC), you can assign specific admin roles ( Full admin, Policy admin, Support, and Auditor) within your Zivver organization settings, streamlining user management and enhancing security. RBAC helps to improve the efficiency of your administrative processes while safeguarding impactful functionalities & information. On this page you can read all about using RBAC in Zivver for your organization.
Tip
Advanced Administration Bundle
Role-Based Access Control is part of our Advanced Administration Bundle, containing capabilities that larger organizations require while SMBs do not. Please contact your contact person at Zivver or our support team if you are interested in this feature.
Change roles
Follow these steps to set admin roles:
Log in to the Zivver WebApp as Full Admin.
Any existing admin before RBAC was enabled will have the Full Admin role.
Click Organization Settings.
Expand User administration.
Click Accounts.
Click Manage next to the account for which you want to change the role.
Scroll down to the Account type pane.
Select Administrator.
Choose a role from the Administrator role dropdown menu.
Click Save.
Review and confirm your changes.
If this account was not an administrator yet and Single Sign-On is enabled, you need to enter a temporary password for the account
Roles
With RBAC, access to the Zivver organization settings can be granted based on four common administrative roles:
- Full admin: Full edit access to all settings and the ability to manage the roles of other admins
- Policy admin: Edit access to all settings, except for the most impactful settings that only need to be configured once, plus access to audit and communication logs
- Support: Edit access to user accounts, but no access to impactful account settings or sensitive data
- Auditor: Read-only access to all settings, no ability to make changes
Warning
Access to sensitive data
To perform tasks for effective Zivver administration, both Full admin and Policy admin must be able to perform actions that can grant access to other usersβ message data (such as password resets or delegated access). Keep this in mind when assigning these roles.
Permission overview
In this overview, π indicates View (Read-only) permission and βοΈ indicates Edit (Write) permission for a scope. If no icon is displayed, the role has no permission.
| Scope | Full admin | Policy admin | Support | Auditor |
|---|---|---|---|---|
| General | ||||
| Get started page | π | π | π | π |
| Organization account information (logo, branding, name, business holder) | βοΈ | π | π | π |
| Data export host and username (excl. password) | π | π | π | |
| List domains and (DNS) settings | βοΈ | π | π | |
| Inbound Direct Delivery settings | βοΈ | π | π | |
| NTA-7516 sending settings | βοΈ | π | π | π |
| Organizational units | βοΈ | βοΈ | βοΈ | π |
| Organization subscription | βοΈ | π | π | π |
| Contact support page | π | π | π | π |
| User administration | ||||
| Account details (name, picture, language, timezone, displayed sender) | βοΈ | βοΈ | βοΈ | π |
| Email aliases | βοΈ | βοΈ | π | π |
| Delegations | βοΈ | βοΈ | π | π |
| Password reset | βοΈ | βοΈ | ||
| Communication log | π | π | ||
| Accounts that need restoring after password reset | βοΈ | βοΈ | βοΈ | π |
| Authentication factors | βοΈ | βοΈ | βοΈ | π |
| Logout active sessions | βοΈ | βοΈ | βοΈ | π |
| Administrator role | βοΈ | π | π | π |
| Account type (user or functional) | βοΈ | βοΈ | π | π |
| Account status (active or suspended) | βοΈ | βοΈ | βοΈ | π |
| Single Sign On settings | βοΈ | π | π | |
| Trusted networks | βοΈ | βοΈ | π | |
| Automatic account deletion | βοΈ | π | π | |
| Insights | ||||
| Insights without personal data | π | π | π | |
| Insights with personal data | π | π | ||
| Audit log | π | π | ||
| Policies | ||||
| Recipient verification | βοΈ | βοΈ | βοΈ | π |
| Verification methods allowed | βοΈ | βοΈ | π | |
| Trusted devices allowed | βοΈ | βοΈ | π | |
| Outbound direct delivery | βοΈ | βοΈ | π | |
| Business rules | βοΈ | βοΈ | π | |
| Trusted domains | βοΈ | βοΈ | π | |
| Organization revocation policy | βοΈ | βοΈ | π | |
| Plugin settings | βοΈ | βοΈ | π | |
| Recipient Experience | ||||
| Notification message | βοΈ | βοΈ | π | |
| Introduce Zivver settings | βοΈ | βοΈ | π | |
| Conversation starters | βοΈ | βοΈ | π | |
| Organization displayed sender | βοΈ | βοΈ | π | π |
| Custom support channels | βοΈ | βοΈ | π | |
| Integrations | ||||
| SMTP credentials | βοΈ | π | π | |
| DLP Gateway | βοΈ | βοΈ | π | |
| API keys | βοΈ | π | π | |
| Google Workspace Key | βοΈ | π | π | |
| Grant users access to Chrome Extension Service Account Key | βοΈ | π | π | |
| Downloads page | π | π | π | π |
Frequently asked questions
Who can reset passwords or change primary emails of other admins?
For security reasons, only the Full Admin can reset the password or change the primary email address of any other admin. This restriction prevents restricted admins from accessing other adminsβ accounts and performing actions that require higher privileges.
Does RBAC also apply to usersβ personal settings?
No, this functionality applies only to admin settings. It does not affect changes that users can make to their own personal profile settings (as shown in this screenshot).
What does View or Edit permission mean for (secret) keys and credentials?
Keys or credentials (API keys, SMTP credentials, and Google Workspace Key) are never displayed. View permission allows viewing (a list of) the created keys. Edit permission allows creating, deleting, and, if applicable, disabling credentials.
What permissions are needed for data export?
Only a Full Admin can perform data export, and only if this functionality has been explicitly enabled for the organization. Data export requires both Edit permission for API keys and View permission for the data export host and username. The API key is used for authentication and is required alongside the host and username. For data protection reasons, data export is disabled by default and must be enabled by Support before use.
Why is it recommended to have at least two Full Admins?
This prevents a single point of failure. The Full Admin is the only role with full access to the organization and can restore access for other Full Admins. Therefore, it is strongly recommended that an organization always has at least two Full Admins.
Can an admin change their own role?
An admin cannot change their own administrator role (or account type). This prevents a situation where no Full Admins remain in the organization.
Why can Support not edit all user settings?
For data protection, the Support role cannot add aliases or delegations, change account types, or reset passwords. Without this restriction, a Support admin could gain access to other usersβ messages, which is an unacceptable data security risk. Certain user settings can only be edited by Full or Policy Admins.
Are API keys affected by changing an admin role?
No, changing an admin role only affects the ability to create new API keys in the admin portal. Existing API keys are not affected.
At what level are restricted admins blocked from performing certain actions?
Actions disallowed for a role are blocked at the API endpoint level. This means administrators cannot perform these actions through the admin portal or by directly calling API endpoints via another client. Administrators who do not require cryptographic access to organization data for their role will not have such access.
Updated on 2026-07-03