Skip to main content
Flashduty uses two types of permissions: functional permissions and data permissions, which work together in different feature scenarios.
You must have both functional permissions and data permissions to operate on certain data objects. Functional permissions are a prerequisite, determining whether you can perform a certain type of operation; data permissions further define the scope of data you can operate on.

​
Functional permissions

Functional permissions, also known as operational permissions, determine which system features or operations a user can access. This includes: whether APIs can be called, whether buttons are clickable, and whether pages and menus are visible.
Flashduty controls functional permissions based on roles (RBAC), with permissions divided by modules for fine-grained management. The system provides the following preset roles (you can also create custom roles):

​
Preset roles

Has all permissions, for core members who manage everything. The Admin permission bitmap queries account_id IN (0, current account ID) with no upper bound on permission IDs. It therefore includes every custom menu permission in the account without explicit binding.
Has all system permissions except “Payment Center”, “Members Manage”, “Roles Manage”, and “SSO Manage”. Suitable for members handling daily operations work. The Responder query includes system permissions and current-account permissions (account_id IN (0, current account ID)); permissions marked admin_only=1 are excluded from the Responder preset role. Therefore, non-admin-only account-level dynamic permissions, including custom menu access permissions, are included automatically.
Has most read-only system permissions except “Audit” and “Onboarding”. Suitable for members who only need to view data. Viewer is subject to the id < 100000 filter and does not automatically inherit custom menu access — explicit role binding is required per menu.
The Responder role does not include member management and role management permissions. To manage team members or assign roles, use the Admin role.

​
Permission list

The system divides permissions by product scope, with each permission point having Read and Manage types. The console groups permissions under the following product scopes, each with a corresponding icon:
  • Platform: Organization management, payment center, and other foundational platform permissions
  • On-call: Incident response, configuration management, status pages, and other on-call related permissions
  • RUM: Frontend monitoring related permissions
  • Monitors: Monitoring and alerting related permissions
  • Custom menu: Account-level dynamic permission group; each configured custom menu becomes a permission point
When a permission point has both Read and Manage types, granting Manage permission automatically includes the corresponding Read permission — no need to select it separately.

​
System vs. account-level dynamic permissions

Flashduty’s permission points fall into two categories:
  • System permissions: Defined by Flashduty and identical across all accounts. They cover the built-in modules: Platform, On-call, RUM, Monitors.
  • Account-level dynamic permissions: Generated from resources configured by the current account, and only visible within that account. The custom menu visit permissions are the canonical example — every custom menu the account adds spawns a matching permission point.
The role configuration API returns the following fields on each permission object so you can tell the two apart:

​
Custom menu permission group

Custom menu is a standalone permission scope, displayed alongside Platform, On-call, RUM, and Monitors. The group is rendered as a flat list — it is not further split into Read / Manage subclasses. Every custom menu configured under the account adds one permission point to this group:
  • Naming: customMenu:visit:<menu_id>, where <menu_id> is the unique identifier of the custom menu.
  • Effect: Members granted this permission can see and visit the corresponding custom menu in the navigation; without it, the menu is hidden.
  • Dynamic behavior: Deleting a custom menu removes the matching permission point. After adding one, re-enter role editing to grant it to the relevant roles.
Custom menu permissions follow different inheritance rules depending on the preset role:
  • Admin: Automatically inherits every custom menu visit permission in the account — no additional configuration needed.
  • Responder: automatically includes custom menu permissions that are not admin-only; admin-only menus are excluded.
  • Viewer: does not automatically get custom menu permissions. To let Viewer members access a custom menu, add Viewer explicitly in that menu’s role binding.
  • Custom roles: Also do not automatically inherit custom menu permissions; explicit binding per menu is required.
For creating and managing custom menus themselves, use Platform Management → Custom Menu; this section only documents the permission semantics.

​
Custom roles

In addition to preset roles, you can create custom roles for more granular permission control. Configuration path: Platform Management → Role Management
1

Create Role

Go to the role management page and click Create Role, then fill in the role name and description. You can also quickly create a role by copying an existing one.
2

Edit Role Information

On the role detail page, click the edit icon (pen icon) next to the role name or description to edit them inline. Flashduty saves changes automatically.
3

Configure Permissions

On the role detail page under the Permission List tab, click Edit to enter editing mode. In editing mode, you can batch select to grant or revoke multiple permission points at once, then click Save when done.
4

Assign Members

On the role detail page under the Authorized Members tab, click Edit to enter editing mode. Use batch selection to add or remove members for this role, then click Save.
  • System preset roles (Admin, Responder, Viewer) cannot be modified or deleted
  • Custom roles support editing, copying, enabling/disabling, and deletion
  • You can’t delete a custom role that any saved SSO configuration (SAML2.0 / OIDC / CAS) uses as its default role. Force delete doesn’t help, because it only removes member bindings. First deselect it as the default role in that SSO configuration. This applies even when SSO or role sync is off
  • A member can hold multiple roles simultaneously; their effective permissions are the union of all assigned roles

​
Permission matrix

​
Data permissions

Data permissions, also known as access permissions, control the scope of data a user can access or view.
Functional permissions are a prerequisite for data permissions. You must first have the corresponding functional permissions for data permissions to take effect. For example: a member with the Viewer role belongs to Team A, and a channel belongs to Team A and is set to private. Although the member has data permissions to access this channel, since Viewer does not have channel management functional permissions, they can only view but not edit.
Flashduty controls data permissions based on teams, applied in the following scenarios:
Channel-exclusive integrations vs shared integrations: an integration created under a channel (its ref_id looks like c_<channel_id>) is a channel-exclusive integration; every other integration is a shared integration. The two follow different permission rules.
  • Functional permissions: either Channels Manage or Integrations Manage lets you enable, disable, delete, and save a channel-exclusive integration. Channels Manage already covers creating, editing, deleting, enabling, disabling and rotating the key of the integrations inside that channel.
  • Data permissions: a channel-exclusive integration is judged by the channel’s managing team; when the channel has no managing team configured, it falls back to the channel’s own team. A shared integration is judged by the integration’s own creator and responsible team.
  • Who can operate: For a channel-exclusive integration, account admins, the channel creator, or the managing team. For a shared integration, account admins, the integration creator, or the managing team.
  • Only integrations created inside a channel are channel-exclusive; a shared integration opened from a channel is still treated as shared.
When you don’t have data permissions for a resource, the system will display the following message:
Insufficient Permission Prompt

​
Legacy role migration

The following legacy preset roles were deprecated on January 30, 2026, and the system has already migrated them.

​
Legacy role description

​
Migration mapping

​
Compatibility notes

The following scenarios will automatically grant the Viewer role to ensure members have basic access permissions:
Compatibility period ends: June 30, 2026After this date, API requests without specifying a role will return an error. Complete the adaptation in advance.
Users with custom roles should check their permission configuration after the upgrade to ensure it meets expectations.

Team Management

Learn about team and member management

Single Sign-On

Configure SSO for unified identity authentication