> ## Documentation Index
> Fetch the complete documentation index at: https://docs.flashduty.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Custom Menu
> Embed custom links or internal pages in the Flashduty console sidebar, with role-based visibility control
Custom menus let administrators add navigation entries to the console sidebar, embedding external system pages or internal links directly into the Flashduty navigation tree. Each menu item corresponds to an account-scoped permission that must be explicitly granted per role before the entry becomes visible to members.
**Navigation path**: Platform → Custom Menu
## Create a menu
Go to **Platform → Custom Menu** and click **New Menu**.
Complete the following fields:
| Field | Required | Limit | Description |
| ----------------------------- | :------: | ------------------ | --------------------------------------------------------------------------------- |
| **Chinese label** (label\_zh) | Yes | Max 128 chars | Menu name shown in the Chinese locale |
| **English label** (label\_en) | No | Max 128 chars | Menu name shown in the English locale; falls back to the Chinese label if omitted |
| **Icon** (icon) | No | Max 255 chars | Icon identifier for the menu entry |
| **URL** (url) | Yes | Max 2048 chars | Target URL to open or embed when the menu is clicked |
| **Open mode** (mode) | Yes | `iframe` or `open` | See description below |
| **Authorized roles** | No | — | Roles that can see this menu; if empty, no regular members can see it |
The open mode determines what happens when a user clicks the menu entry:
* **iframe**: Renders the target page inside the console main content area as an embedded frame. Use this for internal tools you want members to access without leaving Flashduty — for example, a Grafana dashboard or an internal knowledge base. The target page must permit iframe embedding (its HTTP response headers must not set `X-Frame-Options: DENY` or `X-Frame-Options: SAMEORIGIN`).
* **open**: Opens the target URL in a new browser tab. Use this for external systems or pages that do not support iframe embedding.
In the **Authorized roles** field, select which roles are allowed to see this menu entry.
System preset roles (**Admin**, **Responder**, **Viewer**) cannot be bound to a custom menu because they already inherit every account-level permission at runtime. Use **custom roles** for authorization instead.
If no roles are selected, the menu entry is invisible to all regular members. The account owner and Admin-role members can still access the menu through the administration interface.
Click **Save**. The system automatically generates a permission key for this menu (format: `customMenu:visit:`) and writes it into the permission bitmap of every selected role.
## Edit a menu
Click the **Edit** button next to a menu in the list to modify any of its fields.
When you change the **Authorized roles** field, the system performs a full sync: roles in the new list gain access, roles removed from the list lose access. If you submit an edit without including the roles field, the existing role bindings are left unchanged — this is the intended behavior for rename-only or URL-only edits.
## Delete a menu
Click the **Delete** button on any row to remove that menu. Deletion also removes the associated permission key and clears the corresponding bit from every role's permission bitmap. **Members holding those roles will no longer see the menu entry after their next login or permission refresh.**
Deletion is idempotent: deleting an already-deleted menu returns success, so the client can safely retry on network failures.
## Menu ordering
The menu list supports drag-and-drop reordering. Positions are persisted using the LexoRank algorithm, which handles repeated mid-point insertions without requiring compaction.
## Quota
Each account can have at most **100** custom menus. When the quota is reached, create requests return an error. Delete unused menus before adding new ones.
## Permission details
Custom menus use account-scoped dynamic permissions. These appear alongside system permissions in the role editor under the **Custom Menu** group:
* **Permission key format**: `customMenu:visit:`, where `` is the numeric identifier assigned by the system when the menu was created.
* **Visibility control**: Only members whose roles include the corresponding permission key can see the menu entry in the sidebar. Members without the permission see no entry and cannot trigger navigation highlighting by visiting the URL directly.
* **Account owner**: The account owner (the person whose ID equals the account ID) bypasses the permission filter and can always see all custom menus.
* **Permission lifecycle**: When a menu is deleted, its permission key is invalidated and the bit is cleared from all role bitmaps. When a new menu is created, you must explicitly grant its permission key to the desired roles — existing roles do not automatically gain access to newly created menus.
For the complete semantics of `customMenu:visit:` in the Flashduty role system, see the "Custom Menu Permission Group" section in [Permission Design](/en/platform/permission-design).
## Further reading
Understand Flashduty's RBAC permission system and account-scoped dynamic permissions
Manage teams and members, configure roles and access control