Explore permissions
Use this page to grant appropriate access for Explore. Permissions apply in two layers:
- Role-based permissions — global, per-resource-type access (for example, the ability to read or manage any saved view in Explore).
- Resource-level access policies — fine-grained rules on each individual saved view (for example, sharing a single view with a specific group). See Access policies for the full model.
For the complete list of every Coralogix permission, see Permissions list.
Saved views
These permissions control who can read and manage saved views in Explore, and who can edit each saved view's access policy.
| Resource | Description | System roles | API presets |
|---|---|---|---|
EXPLORE-SAVED-VIEWS:READ | View saved views in the Explore Screen. | Data Admin, Observability Lead, Platform Admin, Read-Only User, Security User, Standard User | SavedViews |
EXPLORE-SAVED-VIEWS:MANAGE | Manage saved views in the Explore Screen. | Data Admin, Observability Lead, Platform Admin, Read-Only User, Security User, Standard User | SavedViews |
EXPLORE-SAVED-VIEWS:READACCESSPOLICY | View access policies for Explore saved views. | Data Admin, Observability Lead, Platform Admin, Security User | SavedViews |
EXPLORE-SAVED-VIEWS:UPDATEACCESSPOLICY | Manage access policies for Explore saved views. | Data Admin, Observability Lead, Platform Admin, Security User | SavedViews |
Team default view
These permissions control who can see or set the team-level default view that all team members land on in Explore. By default, only Platform Admin has them.
| Resource | Description | System roles | API presets |
|---|---|---|---|
EXPLORE-TEAM-DEFAULT-VIEWS:READ | View the team-level default view in Explore settings. | Platform Admin | SavedViews |
EXPLORE-TEAM-DEFAULT-VIEWS:MANAGE | Define the team-level default view in Explore settings. | Platform Admin | SavedViews |
Individual users do not need either permission to override the team default for themselves — overriding happens through the Set as default view toggle on any saved view they can already read.
Companion permissions for sharing a view
When you build an access policy on a saved view, you also need these companion permissions to select target groups and (optionally) override policies platform-wide.
| Resource | Description | System roles |
|---|---|---|
TEAM-GROUPS:READSUMMARY | List groups available as policy targets. | Data Admin, Observability Lead, Platform Admin, Security User, Standard User |
TEAM-GROUPS:READCONFIG | View group details when building a policy. | Data Admin, Observability Lead, Platform Admin, Security User, Standard User |
access-policies:ReadAll | View any access policy across resources (override). | — (not included in system roles by default) |
access-policies:UpdateAll | Modify or delete any access policy across resources (override). | — (not included in system roles by default) |
LiveTail
Access to LiveTail is gated by a separate permission. Without it, the /livetail route returns a permission error.
| Resource | Description |
|---|---|
LIVETAIL:READ | Open the LiveTail screen and stream logs in real time. |
Companion features gated elsewhere
Two action buttons in the Explore top bar — Create alert and Save to dashboard — are always rendered for any user with Explore access. The permission check happens in the dialog that opens, not in Explore itself:
- Create alert requires the standard alerts-management permissions, resolved by the alert editor.
- Save to dashboard requires the dashboard-create permissions, resolved by the dashboard picker.
If a user can open Explore but can't follow through on these actions, double-check the permissions on those features in their respective pages.
The Create metric alert action in the value menu has its own pair of gates — it only appears for numeric values and when the user holds both the Events2Metrics and the metric-alert update permissions. See the metric-alerts page for the exact permission strings.
Legacy permissions during migration
During the per-feature policy-based access control migration, the legacy TEAM-SAVED-VIEWS and USER-SAVED-VIEWS permission keys still control access for backends that have not yet flipped to EXPLORE-SAVED-VIEWS. They act as a fallback and will retire once all features migrate. Granting either set is sufficient for users to access saved views in Explore.
| Resource | Description |
|---|---|
TEAM-SAVED-VIEWS:READ / :UPDATE / :READACCESSPOLICY / :UPDATEACCESSPOLICY | Legacy resource that gated public shared views before the per-feature migration. |
USER-SAVED-VIEWS:READ / :UPDATE | Legacy resource that gated private shared views before the per-feature migration. |
Related resources
- Tabs, views, and queries — saved view UI walk-through including the Access policy widget.
- Access policies overview — the cross-product model for resource-level access control.
- Permissions list — complete list of every Coralogix permission.