# Access policies

Policy-based access control gives you precise control over who can view, manage, or perform other supported actions on specific resources in Coralogix. It adds resource-level policies on top of your existing role-based permissions, so you can set rules per resource and per action instead of granting broad access to everyone who can access that resource type.

By combining access policies with groups, you can keep sensitive content private, create team-level silos, reduce dashboard and alert noise, personalize views, and make sure each team sees only what's relevant.

Use access policies to:

- Secure resource-level access for dashboards, datasets, alerts, Team API keys, and more.
- Streamline workflows by showing users only the resources they need.
- Reduce risk by limiting exposure to sensitive content using group-based rules.
- Enable secure collaboration across teams, managed service providers, or customers.

## How permissions and policies work together

- Role-based permissions determine whether a user can access a type of resource at all (for example, dashboards).
- Access policies fine-tune access for each individual resource (for example, a specific dashboard), including what actions a user or group can perform.

## Why use access policies

| Team                          | How access policies help                                                                                             |
| ----------------------------- | -------------------------------------------------------------------------------------------------------------------- |
| Admins and org owners         | Reduce data exposure, enforce least privilege, and support isolated team models for MSP and multi-team environments. |
| Security teams                | Protect sensitive content and enforce separation between teams or domains.                                           |
| DevOps and SRE                | Cut dashboard and alert noise by limiting visibility to owned resources.                                             |
| Developers                    | Work privately until ready to share, without changing role-based permissions.                                        |
| Data and observability admins | Restrict access to specific datasets and other high-impact resources.                                                |

## Understand policy-based access control

[Role-based permissions](https://coralogix.com/docs/user-guides/aaa/access-control/permissions/index.md) define global access by resource type, and policies refine access for specific resources.

For example:

- Global permissions can grant a user read access to Custom Dashboards, but a policy that denies access to a specific dashboard overrides this.
- Global permissions can grant a user read and manage access to datasets, but a policy for a specific dataset can restrict or extend this further.

When you configure a policy on a resource for the first time, the default general access reflects existing system behavior.

## Access modes

Every access policy starts with a top-level mode selector — **Who can access this `<resource>`** — that controls how much of the editor is exposed:

- **Private** — only you can view and edit the resource. No other configuration is needed; this is the default for newly created resources.
- **Public** — anyone in the team with role-based access to this resource type can view and edit it. No other configuration is needed.
- **Advanced** — opens the full policy editor, with target group rules and general access. Use Advanced when you need to share a resource with specific groups or set broad team-wide access.

## Supported features

Policies are currently available for the following Coralogix features:

- [Custom Dashboards](https://coralogix.com/docs/user-guides/custom-dashboards/tutorials/manage-dashboard-settings/#access-policies)
- [Team and Send-Your-Data API Keys](https://coralogix.com/docs/user-guides/account-management/api-keys/api-keys/#access-policies-for-api-keys)
- [Datasets](https://coralogix.com/docs/user-guides/data-layer/dataset-management/access-control/index.md)
- [Explore](https://coralogix.com/docs/user-guides/monitoring-and-insights/explore-screen/create-and-manage-saved-views/index.md)

## What you need to get started

To create or edit a policy for a resource, you must first have all required [permissions](#permissions), including role-based permissions that grant you eligibility to the resource type.

## Create a policy

Follow these steps from the resource settings panel.

### Step 1. Open the resource settings

Navigate to the resource (for example, a Custom Dashboard). Open its settings from the settings icon or more actions menu, then scroll to the **Access Policy** section.

### Step 2. Select an access mode

Use the **Who can access this `<resource>`** dropdown to pick a mode:

- **Private** — only you can view and edit the resource. No further configuration is needed; skip to [Step 5](#step-5-save-your-changes) to save.
- **Public** — anyone in the team with role-based access to this resource type can view and edit it. No further configuration is needed; skip to [Step 5](#step-5-save-your-changes) to save.
- **Advanced** — opens the full policy editor for target group rules and general access. Continue with Steps 3–4 below.

Note

Steps 3 and 4 apply only to **Advanced** mode. If you chose Private or Public, go straight to [Step 5](#step-5-save-your-changes).

### Step 3. Apply to target groups (Advanced, optional)

In the **Apply to target groups** section, define per-group access. Rules target groups only — to grant access to an individual user, create a single-member group.

1. Search for and select a group in the group field.
1. Select an access level from the action dropdown. Available options differ by resource type — for example, **Read**, **No Access**, or **Manage** for saved views.
1. Select **Apply** to commit the rule.
1. Repeat to add more rules. To remove a rule, select the remove icon next to it.

### Step 4. Set general access (Advanced)

In **General access**, select the default access level for everyone on your team who isn't covered by a target group rule. Available options differ by resource type.

### Step 5. Save your changes

Select **Save** to activate the policy. To restore the default configuration, select **Reset**.

The screenshot below shows the **Access Policy** panel in **Advanced** mode on an Explore saved view, with two target-group rules (`Admins` → **Manage**, `Analysts` → with the access-level dropdown open) and **General access** set to everyone in the team.

## Restricted group behavior

If the policy creator belongs to one or more [restricted groups](https://coralogix.com/docs/user-guides/account-management/user-management/assign-user-roles-and-scopes-via-groups/index.md), the system:

1. Converts the general access setting into per-restricted-group rules.
1. Sets general access to the restricted-group default (typically no access).

This makes content created by restricted-group members private-first by default.

## Configuration examples

Level names in the steps that follow — **Read**, **Manage**, **No Access** — match the saved-views UI. The names differ by resource type (for example, datasets expose `readData`, `overwriteData`, `appendData`, `readAccessPolicy`, and `updateAccessPolicy`). The configuration pattern is the same in every case.

### Only me (Private)

- **Goal**: No one else can view, manage, or take any other action.
- **Steps**:
  1. Set the mode to **Private**.
- **Result**: Only the policy owner has access.

### Team-only

- **Goal**: Only the `App A Devs` group can read (and optionally manage).
- **Steps**:
  1. Set the mode to **Advanced**.
  1. Set **General access** to **No Access**.
  1. In **Apply to target groups**, add a rule: target `App A Devs` → **Read** (or **Manage** if needed). Select **Apply**.
- **Result**: Users in `App A Devs` can read or manage; others are denied.

### Everyone, except group X

- **Goal**: Broad read access for all, except block the `London` group.
- **Steps**:
  1. Set the mode to **Advanced**.
  1. Set **General access** to **Read**.
  1. In **Apply to target groups**, add a rule: target `London` → **No Access**. Select **Apply**.
- **Result**: All users can read, except the `London` group.

### Read-only for all; Product-Managers can manage

- **Goal**: Everyone can read; `Product-Managers` can also manage.
- **Steps**:
  1. Set the mode to **Advanced**.
  1. Set **General access** to **Read**.
  1. In **Apply to target groups**, add a rule: target `Product-Managers` → **Manage**. Select **Apply**.
- **Result**: All users can read; `Product-Managers` can manage.

### Sensitive dashboard visible only to SOC-Analysts

- **Goal**: Keep it private to `SOC-Analysts`.
- **Steps**:
  1. Set the mode to **Advanced**.
  1. Set **General access** to **No Access**.
  1. In **Apply to target groups**, add a rule: target `SOC-Analysts` → **Read** (and **Manage** if needed). Select **Apply**.
- **Result**: Only `SOC-Analysts` have access.

### Allow everyone to read; Developers can manage

- **Goal**: Broad visibility, controlled changes.
- **Steps**:
  1. Set the mode to **Advanced**.
  1. Set **General access** to **Read**.
  1. In **Apply to target groups**, add a rule: target `Developers` → **Manage**. Select **Apply**.
- **Result**: All users can read; `Developers` can manage.

## Permissions

To create or edit a policy for a resource, the following requirements must be met cumulatively.

### Global resource permissions

You must have global permissions that grant you visibility and management of the resource itself: `<resource_type>:Read` and `<resource_type>:Manage`.

### Policy owner permissions

As a policy creator, you automatically get permissions to view and update a resource's policy: `<resource_type>:ReadAccessPolicy` and `<resource_type>:UpdateAccessPolicy`.

As long as your policy is active, users with `access-policies:UpdateAll` and `access-policies:ReadAll` can override resource-specific policy permissions and disable your policy, effectively becoming the new policy owners.

Note

The resource's creator does not need to be the policy owner. One user can create a resource, and another user can create and own its policy.

### Target group permissions

To select and view target groups when building a policy, you need the following:

- `team-groups:ReadSummary`
- `team-groups:ReadConfig`

## Overriding access policies

Where appropriate, grant wide policy maintenance permissions so designated users can find and fix stale policies:

- `access-policies:ReadAll`
- `access-policies:UpdateAll`

These powerful permissions are not included in any out-of-the-box system roles.

## What happened to Scopes?

[Scopes](https://coralogix.com/docs/user-guides/account-management/user-management/scopes/) are a legacy access mechanism still used by some resource types (for example, default `/logs` and `/spans` datasets). They continue to work alongside policies in the legacy API.

For legacy scopes, membership is also additive — the user's visible data is the union of all group scopes they belong to.

## FAQs

### Q: I can't see the Access policy section. Why?

You don't have permission to create or edit policies for this resource.

Ask your admin to check your `<resource_type>:ReadAccessPolicy` and `<resource_type>:UpdateAccessPolicy` permissions for this resource type.

### Q: I can't see groups when adding a rule. Why?

You may be missing the `team-groups:ReadSummary` permission.

Ask your admin to enable it.

### Q: I can see some groups, but not all of them. Why?

Even if you have `team-groups:ReadSummary`, visibility still depends on the group type.

You can see:

- Open groups
- Private or restricted groups you are a member of

You can't see:

- Private or restricted groups you are not part of

### Q: I lost access to a policy I created. How can that happen?

Common reasons:

- You lost the global permissions required to view or manage policies.
- An admin or user with `access-policies:ReadAll` and `access-policies:UpdateAll` permissions replaced or removed your policy.

### Q: I lost access to a resource. How can that happen?

Possible causes:

- You were removed from a private/restricted group included in the policy.
- The group used by the policy was deleted.
- Another user with permissions updated the policy and changed who is allowed.