Documentation Grafana Cloud Alerts and IRM IRM Guides Best practices Teams and access control

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

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).

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:

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:

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 Users and teams.

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.

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 for details.

Organization-wide settings

Organization settings control behavior across all teams and users.

Alert behavior settings

Configure how IRM handles alert acknowledgment and resolution.

Acknowledge remind timeout:

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

Unacknowledge 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:

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:

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.
• Regular security reviews: Verify permissions and review audit logs.

Next steps

• Manage users and teams in detail
• Configure notification rules
• Set up infrastructure as code for automated management