---
title: "Best practices for teams and access control | Grafana Cloud documentation"
description: "Best practices for organizing teams, managing permissions, and configuring access control in Grafana IRM."
---

> For a curated documentation index, see [llms.txt](/llms.txt). For the complete documentation index, see [llms-full.txt](/llms-full.txt).

# Best practices for teams and access control

Proper configuration of users, teams, and organization settings ensures the right people have access to the right resources while maintaining security.

## Understand the organizational structure

Before configuring access, understand how IRM organizes resources.

### The hierarchy

IRM uses a three-level hierarchy:

text ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy

```text
Organization
    └── Teams
            └── Users
```

- **Organization:** The top level containing all IRM resources and settings.
- **Teams:** Groups of users who share responsibility for services and resources.
- **Users:** Individual people who interact with IRM.

### How resources are organized

Most IRM resources belong to teams:

- Integrations
- Escalation chains
- Schedules
- Routes

Organization-wide settings apply across all teams:

- Alert behavior (acknowledgment timeouts)
- Integration controls (which platforms are enabled)
- Security settings (team membership requirements)

Users can belong to multiple teams and see resources from all their teams.

## Configure teams

Teams are the foundation for organizing on-call responsibilities and resource access.

### Team design principles

Design teams around operational responsibility:

- **Service ownership:** Teams own specific services or domains.
- **On-call rotation:** Team members share on-call duties.
- **Resource access:** Teams manage their own integrations, schedules, and chains.

### Team membership

Users can belong to multiple teams:

- **Primary team:** Main responsibilities.
- **Secondary teams:** Cross-functional work.
- **Resource visibility:** Users see resources from all their teams.

### Team access control

Two settings work together to control access to team resources.

**Team visibility** (per-team setting):

Controls who can **see** team resources. Configure through **Team Access Management** (called `is_sharing_resources_to_all` in the API/Terraform).

Expand table

| Setting                        | Behavior                                        |
|--------------------------------|-------------------------------------------------|
| All users of Grafana (default) | All organization users can view team resources  |
| Only admins and team members   | Only team members and admins can view resources |

**Team membership enforcement** (organization setting):

Controls who can **edit** team resources. Enable **Require team membership for updates** (called `require_team_membership_for_updates` in the API/Terraform).

When enabled, only team members can modify team resources. Admins and service accounts bypass this restriction.

### Access control patterns

Combine these settings to achieve different access patterns:

Expand table

| Team visibility              | Membership enforcement | Result                                            |
|------------------------------|------------------------|---------------------------------------------------|
| All users                    | Disabled               | Open: anyone can view and edit (with role)        |
| All users                    | Enabled                | View-only sharing: anyone views, members edit     |
| Only admins and team members | Either                 | Private: only members and admins can view or edit |

**Recommendations:**

- **Most teams:** Use defaults (visible to all, role-based editing).
- **Shared resources:** Enable membership enforcement to allow viewing but restrict editing.
- **Sensitive teams:** Set to “Only admins and team members” for security, payments, or PII.

## Manage users and permissions

Configure user access to match your organization’s security and operational needs.

### User roles

IRM supports both legacy roles and RBAC.

**Legacy roles** provide basic access levels:

Expand table

| Role   | Access                      |
|--------|-----------------------------|
| Admin  | Full access                 |
| Editor | Create and modify resources |
| Viewer | Read-only access            |

**RBAC** provides granular permissions:

- Provides fine-grained permissions per resource type.
- Supports read, write, and admin actions.
- Offers more flexibility for complex organizations.

RBAC is enabled by default in Grafana Cloud. Use RBAC to grant specific permissions without changing users’ organization-level roles.

For details on available RBAC roles, refer to [Manage access](/docs/grafana-cloud/alerting-and-irm/irm/set-up/manage-access).

### Service accounts

Use service accounts for automation and integrations.

**Use cases:**

- Terraform and IaC automation.
- CI/CD pipeline integrations.
- API-based tooling.

**Benefits:**

- Bypass team membership checks.
- Dedicated credentials for automation.
- Audit trail separate from human users.

**Best practice:** Create dedicated service accounts per use case rather than sharing credentials.

## Customize user preferences

Each user controls a small set of IRM preferences that shape their personal experience, including notification rules and working hours. Encourage your users to review these settings during onboarding so their alerts reach them reliably and their availability is visible to teammates.

For step-by-step instructions, refer to [Configure your user profile](/docs/grafana-cloud/alerting-and-irm/irm/set-up/user-profile).

### Notification preferences

Each user configures their notification preferences:

- **Default notification rules:** For standard alerts.
- **Important notification rules:** For escalated alerts.
- **Notification channels:** Phone, SMS, email, Slack, mobile app.

**Best practices:**

- Encourage users to set up multiple channels for redundancy.
- Verify phone numbers and email addresses work correctly.
- Test notifications during user onboarding.

For on-call handoff notifications, configure timing at the schedule level. Refer to [On-call schedules](/docs/grafana-cloud/alerting-and-irm/irm/on-call-schedules/create-schedules) for details.

### Working hours

Working hours let teammates see when a user is available. When a user has working hours configured, their working hours appear on schedule hover cards so teammates can quickly check whether the user is currently inside or outside their working hours.

**Best practices:**

- Encourage users to enable working hours so on-call coordination accounts for time zones and personal schedules.
- Keep the editor simple: use a single daily time range when possible, and add extra time ranges only for split shifts.
- Remind users to review their working hours after they change timezone or week start preferences.

For configuration details, refer to [Define custom working hours](/docs/grafana-cloud/alerting-and-irm/irm/set-up/user-profile/#define-custom-working-hours).

## Organization-wide settings

Organization settings control behavior across all teams and users. For more information, refer to [Admin settings](/docs/irm/next/guides/set-up/admin-settings)

### Alert behavior settings

Configure how IRM handles alert acknowledgment and resolution.

**Acknowledge remind timeout:**

Expand table

| Setting           | Behavior                     |
|-------------------|------------------------------|
| Never             | No reminders                 |
| 1, 3, 5, 10 hours | Remind if still acknowledged |

Use reminders to prevent alerts from being forgotten in acknowledged state.

**Unacknowledge timeout:**

Expand table

| Setting               | Behavior                         |
|-----------------------|----------------------------------|
| Never                 | Stay acknowledged indefinitely   |
| 5, 15, 30, 45 minutes | Auto-unacknowledge after timeout |

Use auto-unacknowledge for time-sensitive alerts that need attention even after initial acknowledgment.

**Resolution notes:**

Enable **Require resolution note** (called `is_resolution_note_required` in the API/Terraform) to:

- Require documentation when resolving alerts.
- Build institutional knowledge.
- Improve post-incident reviews.

**Recommendation:** Enable for production environments to capture resolution context.

### Notification channel controls

Control which integrations are available for use in notification rules across your organization.

**Communication platforms:**

Expand table

| Setting (API/Terraform name)              | Platform          |
|-------------------------------------------|-------------------|
| `is_slack_integration_enabled`            | Slack             |
| `is_ms_teams_integration_enabled`         | Microsoft Teams   |
| `is_telegram_integration_enabled`         | Telegram          |
| `is_personal_webhook_integration_enabled` | Personal webhooks |

When disabled, users can’t add these platforms to their personal notification rules, even if the integration is installed at the organization level.

### Direct paging management

Direct paging lets users manually page teams or individuals without an external trigger. By default, IRM automatically creates a direct paging integration for each team.

Configure **Manually manage direct paging integrations** (called `manually_manage_direct_paging_integrations`) to control this behavior:

Expand table

| Setting            | Behavior                                        |
|--------------------|-------------------------------------------------|
| Disabled (default) | Auto-create direct paging integrations per team |
| Enabled            | Manage via Terraform/API only                   |

Enable when using Terraform for IRM configuration or when you need strict IaC control.

### Schedule restrictions

Enable **Disable schedule updates in the past** (called `disable_schedule_updates_in_the_past`) to:

- Prevent retroactive schedule changes.
- Maintain accurate historical records.
- Support compliance requirements.

**Consideration:** This may limit flexibility for correcting past schedule errors.

## Security and compliance

Implement security best practices across your IRM configuration.

### Access control best practices

- **Use RBAC:** Leverage fine-grained permissions instead of broad legacy roles.
- **Enable membership enforcement:** For sensitive resources, require team membership to edit.
- **Restrict sensitive teams:** Use private team visibility for security, payments, or PII-related teams.
- **Review access regularly:** Periodically verify permissions remain appropriate.

### Audit trail

IRM tracks all changes:

- Who made changes.
- When changes occurred.
- What was modified.

Review audit logs regularly for:

- Unauthorized access attempts.
- Unexpected configuration changes.
- Compliance verification.

### Credential management

- **Use service accounts:** For automation instead of personal credentials.
- **Rotate tokens:** Regularly rotate integration tokens and API keys.
- **Limit scope:** Restrict API key permissions to what’s necessary.

## Best practices summary

- **Understand the hierarchy:** Organization → Teams → Users.
- **Design teams around ownership:** Align teams with service responsibility.
- **Configure access control:** Use visibility and membership settings together.
- **Use RBAC:** Leverage fine-grained permissions for complex organizations.
- **Use service accounts:** For automation and IaC.
- **Configure alert behavior:** Match acknowledgment settings to your workflow.
- **Enable resolution notes:** Capture knowledge from resolutions.
- **Optional working hours:** Use weekday toggles and up to three time ranges per day so schedules can show availability.
- **Regular security reviews:** Verify permissions and review audit logs.

## Next steps

- [Manage access](/docs/grafana-cloud/alerting-and-irm/irm/set-up/manage-access) in detail
- [Configure notification rules](/docs/grafana-cloud/alerting-and-irm/irm/notify-responders/personal-notification-rules)
- [Set up infrastructure as code](/docs/grafana-cloud/alerting-and-irm/irm/set-up/infra-as-code) for automated management