• /
  • EnglishEspañolFrançais日本語한국어Português
  • 로그인지금 시작하기

Important user and access management concepts

To set up and manage your New Relic users, you should first understand some basic concepts about how our user management system works.

Overview of user access

The access that users have to product features is controlled by two factors:

  • User type (basic user, core user, full platform user): A user's user type is based on how much you expect that user to use New Relic. User type is a billing factor. It's not meant to be a way to set permissions. For more on this, see User type.
  • Role-based access: This is what you use to control your users' permissions through roles (sets of permissions), groups (containers for users), and access grants (links between groups and roles over specific targets).

These are two separate systems. For you to be able to access a New Relic feature, both your user type and role-based permissions must allow that access. For more about the relationship between user type and roles, refer User type and roles. This document focuses on role-based access.

In addition to role-based access, you can also control access to specific log data using data access control, which allows you to restrict which log partitions users can view.

How groups, roles, and access grants control access to New Relic

At New Relic, user groups contain users, and roles contain permissions. You grant access through access grants, which explicitly link groups to roles over specific targets. For a New Relic user to access New Relic features, you must place them in a group that has an access grant with:

  • A specific role (a role being a set of specific, granular permissions).
  • An appropriate target (organization, specific accounts, or target groups, depending on the role's scope).

Organizations with Pro or Enterprise editions can have multiple accounts in their organization, and can create custom roles and groups. You can create custom roles at three different scopes: organization-level for administrative functions, account-level for platform features, or entity-level for fine-grained access to specific resources. Our Free and Standard editions allow only a single account in an organization, and don't let you create custom roles or groups.

When you initially sign up for New Relic, your organization has some built-in role and account assignments for the default User or Admin groups. For example, the Admin group has several access grants that give users in that group broad New Relic access, including organization-level administrative permissions.

Want to control how users access New Relic? Manage authentication domains here.

New Relic user mgmt groups UI - default group assignments

A view of the Access management UI, showing how our default groups (Admin and User) are granted access to roles, accounts, and organization-scoped permissions.

Here's a diagram showing how group access works and how they relate to the broader organization:

New Relic user management diagram

A diagram showing how groups give users in that group access to roles and accounts.

For tips on setting up groups, see our user management tutorial.

Access grants

Access grants are the explicit links that connect groups to roles over specific targets. You create access grants to give users in a group the permissions defined in a role, applied to a particular scope.

Every access grant requires three components:

  • Assignee: The group that receives access.
  • Role: The set of permissions being granted.
  • Target: The resource scope where the role applies.

You can create three types of access grants based on the scope:

Organization grants

You apply organization grants to give a group organization-level permissions. These grants:

  • Target your entire organization.
  • Require organization-scoped roles.
  • Give users permissions for organization-wide functions.

Account grants

You apply account grants to give a group access to platform features within specific accounts. These grants:

  • Require account-scoped roles.
  • Let you select which accounts the group can access.
  • Can include data access policies to control log data visibility.

Group grants

You apply group grants to delegate group management responsibilities. These grants:

  • Require group-scoped roles (like Group Admin).
  • Let you specify which groups the assignee group can manage.
  • Enable distributed user management without broad administrative access.

For step-by-step instructions on creating access grants, see our user management tutorial.

Groups

In New Relic, placing users in a group allows the managing of permissions for multiple users at the same time. For example, if you're using our automated user management feature, you can import a custom group of users (for example, External consultants) from your identity provider service, and then grant a role and an account to that group.

A user must be in at least one group with access to a role and at least one account in order to access New Relic features. Note that groups are not what restrict a user's New Relic permissions: it's the role assigned to that group that grant access to the permissions.

We have two simple user groups available by default. Pro and Enterprise organizations can create custom groups. Users and groups are located within an authentication domain, which is what controls settings related to how users are provisioned (for example, via an identity provider) and how users log in.

Our default user groups

We have two default user groups:

  • User: A user in this group can use and configure our observability and monitoring features but not perform account-level tasks like managing billing or managing other users. It has access to the All product admin role, which grants control over all observability platform tools, and organization-scoped roles with product administration permissions. It does not have access to organization-scoped roles with user management capabilities.
  • Admin: has the All product admin role and in addition has access to organization-scoped roles with all available organization-level permissions. As a result, this group has access to all features, including the higher-level admin features.

To edit the group a user is in, you can go to either the Access management UI and edit a group, or go to the User management UI and edit the user.

Roles

We offer several default roles, but organizations with Pro or Enterprise editions can create their own custom roles at any of the three role scopes.

Role scopes

You can create roles at three different scopes, each serving different purposes:

  • Organization-scoped roles: You apply these roles for organization-wide functions like managing authentication domains, creating accounts, configuring organization settings, or managing scorecards and teams. Standard roles include:

    • Organization manager: Permissions related to organization settings, including adding accounts, and changing the name of the organization and accounts. This also includes sensitive observability tasks, such as deleting certain entities.
    • Authentication domain manager: Permissions related to adding and managing users, including configuring authentication domains and customizing groups and roles. Options within this include:
      • Manage: Can manage all aspects of authentication domains, including configuring domains and adding users.
      • Read only: Can view authentication domain and user information.
      • Add users: Can view user information, and add users to the organization, but lacks other auth domain configuration and management abilities.
      • Read users: Can only view user information.
    • Billing: Lets a user view and manage billing and usage, and data retention. For organizations with multiple accounts, billing is aggregated in the reporting account (usually the first account created in an organization).
    • Organization product admin: Permissions related to organization-scoped observability features like scorecard and team management. This is the organization-scoped equivalent to All product admin.
  • Account-scoped roles: You apply these roles for access to platform features within specific accounts, such as configuring APM settings, managing alerts, or running queries. These are the traditional roles most users work with. Standard roles include:

    • All product admin: Includes all New Relic platform permissions except the ability to manage organization-level settings, users, and billing.
    • Standard user: Provides access to our platform features but lacks permissions to configure those features and lacks organization-level and user management permissions.
    • Read only: Provides read-only access to the New Relic platform.
  • Entity-scoped roles: You apply these roles for fine-grained access to specific resources like individual dashboards, fleets, or alert policies. This enables precise permission control at the individual resource level. You can create custom entity-scoped roles based on your needs.

Important points about roles:

  • Roles are additive: users with multiple roles assigned have the total of all permissions granted by those roles. For example, if you're in a group that gives you the All product admin role in an account, and in another group that gives you a Read only role for the same account, you have both roles, and are not restricted by the Read only role.
  • Your access depends on both your user type and your permissions (learn more).
  • Creating a role doesn't grant access until you create an access grant linking a group to that role.

To view roles and their permissions, go to the Access management UI and click Roles.

Our standard (default) roles

We have several account-scoped standard roles, which are roles that are available by default and that satisfy some common user management use cases.

중요

Note that some of our standard roles have permissions that we don't expose and that aren't available for adding to a custom role. The only standard roles that can be replicated with a custom role are Standard user and Read only; all others have some non-exposed permissions.

Here's a table with our standard roles. To better understand these roles, go to the access management UI and select a role.

Standard roles

Description

User type guidelines

All product admin

This role includes all New Relic platform permissions except the ability to manage organization-level settings, users, and billing. It's an admin role in the sense that it allows the configuration of our platform features (for example, the ability to configure settings), but it doesn't provide organization-level admin permissions (those require the administrative settings).

This role is essentially the Standard user role, below, with the added ability to configure observability features.

Any. Recommended: core or full platform.

Standard user

Provides access to our platform features (for example, APM UI and UI), but lacks permissions to configure those features and lacks organization-level and user management permissions.

Use the access management UI to view the capabilities included in the standard user role across the platform.

Any. Recommended: core or full platform.

Read only

Provides read-only access to the New Relic platform (except for synthetic monitor secure credentials and dashboard permissions).

Any.

For more about how you'd assign roles to groups and create custom roles, see the user management tutorial.

Organization-level permissions

When you create custom organization-scoped roles, you can assign various organization-level permissions including identity and access management, organization settings, and organization product administration. Full platform admins can combine these permissions into custom roles based on your organization's specific needs. Basic users cannot use roles with these permissions.

Group admin

You can create a Group admin role to assign to a group. This role gives the group the ability to add and remove users for one or more groups you select.

With this feature, you can give selected users the ability to add and remove users for a specific group. This may be preferable to granting users the much more powerful organization-scoped roles with full user management permissions. For example, you may have only one or two admins in the company with organization-wide user management permissions, but you may want to give several more managers the ability to manage users for specific teams, and this role is useful for that.

To use the Group admin role, a user must be in a group with organization-scoped roles that include authentication domain management permissions.

Permissions

For information on the permissions that roles have and that are available for addition to custom roles, see Permissions.

Manage users

To learn how to add users, assign them to groups, and create custom groups and roles, see Manage users.

Use the API

For how to manage your users, groups, and roles via API, see our NerdGraph docs.

User management terms and definitions

For an explanation of how user access to accounts and roles works, see User management concepts. Here are some definitions for some of our user management terms:

  • A New Relic organization is the representation of your organization, containing all your accounts, users, and data. For more information, see Organization and account structure.
  • A permission is an ability to use or edit a specific, granular New Relic feature. For more information, see Permissions.
  • A role is a set of permissions. It is what gives a user their permissions. Our default standard roles have various permissions, and you can create custom roles that have custom permissions.
  • A user group has one or more roles associated with it. You assign your users to a group. We have default user groups (Admin and User), and you can make your own groups.
  • An authentication domain contains a set of users who are added to New Relic and who log in to New Relic in the same way.
  • If a user is a basic user, this takes precedence over any role-related permissions. For more on this, see Basic user and roles.
Copyright © 2025 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.