Here we'll explain how New Relic users get access to specific capabilities and specific accounts.
Main ways permission is controlled: user type and roles
When it comes to what New Relic features your users can access, there are two main settings at work:
- The user type: For organizations on our usage-based pricing, your users' user type is a billing factor. The user type is what sets the maximum allowed capabilities a user can access. It's meant to be a fairly long-term setting based on someone's expected New Relic duties.
- The roles assigned: after a user's user type is decided, roles can be used to more precisely control a user's access. Roles are sets of capabilities, which are the granular New Relic abilities (for example, the ability to modify New Relic APM settings). Roles are assigned to user groups via access grants.
Another way to think about the relationship between a user's user type and their assigned roles: a user's user type overrides all role restrictions. For example: a basic user might be assigned a role that has broad New Relic access, but restrictions related to user type take precedence over any role-granted access. To see how user type relates to roles, see the roles table.
This doc is focused on role-related permissions. For details about user types, see User type.
Access grants give user groups access to New Relic
In order for a New Relic user to be able to access any New Relic account or capability, they must be in a group, and that group must have an associated access grant. The access grant is what gives a group of users:
- Access to a specific role (a role being a set of specific, granular capabilities).
- Access to a specific account, or to the entire organization.
Organizations with Pro or Enterprise edition can have multiple accounts in their organization, and can create and configure access grants. Standard edition organizations are only allowed a single account in their organization, and don't have the ability to create or configure access grants.
When you initially sign up for New Relic, your organization has some built-in access grants associated with the default User or Admin groups. For example, the Admin group has several access grants that give any user in that group broad New Relic access, including to the higher level organization-related and user-management-related admin capabilities.
A view of the Access management UI, showing how our default groups (Admin and User) have access grants that associate the groups with a) specific roles, and b) either a specific account or the entire organization. (Note that this UI is available only for users on our newer user model.)
Here's a diagram showing how access grants work and how they relate to the broader organization:
A diagram explaining the concept of how access grants give a user group access to a specific role and a specific account (or the entire organization).
For how to create and manage access grants, see:
Groups
For users on our newer user model, a "group" represents a group of users. Putting 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 assign an access grant to that group, giving those users a specific role on a specific account.
A New Relic user requires assignment to at least one group to get access to any capability or account. And that group must also have an access grant.
It's worth noting that groups are not what restrict a user's New Relic permissions: it's the role assigned to the group that contains the actual capabilities.
We have two default groups (see below). And 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 added and managed (for example, via SCIM provisioning) and how users log in to New Relic.
Our default user groups
We have two default user groups:
- User: This group allows a user to 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 gives access to our observability platform tools, but doesn't have the Organization manager and Authentication manager roles, which give access to the account-level capabilities.
- Admin: has all capabilities, including the organization-level admin abilities. This is the equivalent of having the standard roles of All product admin, the Billing user, the Organization manager and the Authentication domain manager.
To change a user's group, use the User management UI.
Roles
Roles are groupings of capabilities, which are the granular things New Relic users can do (for example, the ability to manage data retention). We have several default roles, described below. And Pro and Enterprise edition organizations can create custom roles.
To view roles and their capabilities, go to the Access management UI and click Roles. Note that the roles UI shows the account-scoped roles but does not show the organization-scoped roles (Organization manager and Authentication domain manager).
Our standard (default) roles
We have several "standard roles," which are roles that are available by default and that satisfy some commonly needed sets of capabilities.
Important
Note that some of our standard roles have hidden capabilities 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 hidden capabilities.
Here's a table with our standard roles. To better understand the account-scoped roles, go to the Access management UI and select a role.
Standard roles | Scope | Description | User type guidelines |
|---|---|---|---|
All product admin | Account | This role includes all New Relic platform capabilities 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 APM settings), but it doesn't provide organization-level admin capabilities. This role is essentially the Standard user role plus the ability to configure platform features. | Any. Recommended: core or full platform. |
Standard user | Account | Provides access to our platform features (for example, APM UI and browser monitoring UI), but lacks permissions to configure those features and lacks organization-level and user management permissions. This role is essentially the All product admin role without the ability to configure platform features. | Any. Recommended: core or full platform. |
Billing user | Account | Provides ability to manage subscriptions and billing setup, and read-only access to the rest of the platform. For organizations with multiple accounts, billing is aggregated in the primary (first-created) account, which is why assigning this role to that primary account grants billing permissions for the entire organization. The billing capabilities associated with this role aren't selectable for addition to custom roles. | Required: core or full platform. |
Authentication domain manager | Organization | Provides all capabilities related to managing users on our newer user model. For important caveats, see Organization-scoped role caveats. For how to grant this role, see Add user management capability. | Required: core or full platform. |
Authentication domain read only | Organization | Provides the ability to view the users and the user management-related settings for your organization. For important caveats, see Organization-scoped role caveats. For how to grant this role, see Add user management capability. | Required: core or full platform. |
Organization manager | Organization | Provides the ability to manage organization settings, including organization structure, name, and preferences. For user-management-related capabilities, use Authentication domain manager. The Organization manager role currently has few capabilities but more will be added. For important caveats, see Organization-scoped role caveats. For how to grant this role, see Add user management capability. | Required: core or full platform. |
Organization read only | Organization | Provides the ability to view organization-level settings. For how to grant this role, see Add user management capability. For important caveats, see Organization-scoped role caveats. | Required: core or full platform |
Read only | Account | Provides read-only access to the New Relic platform (except for synthetic monitor secure credentials). | Any. |
Manage v1 users | Account | For New Relic organizations that existed before July 30 2020 and have users on our original user model, this role lets you manage those "v1" users. This is used primarily for overseeing a user migration process. | Required: full platform. |
For more about how you'd assign roles to groups and create custom roles, see the user management tutorial.
Caveats about organization-scoped roles
Some caveats about organization-scoped roles:
- The organization-scoped roles (Authentication domain manager and Organization manager) are not visible in the Roles UI. This is because they have special capabilities that are not available for addition to custom roles.
- If a user has only an organization-scoped role assigned, they can't access New Relic. They must also be assigned an account-scoped role.
Capabilities
For information on the capabilities that roles have and that are available for addition to custom roles, see Capabilities.
Manage users
To learn how to add users, assign them to groups, and create custom groups and roles, see Manage users.
Tips for creating access grants
Pro and Enterprise edition organizations can create and configure access grants. (Standard edition organizations don't have to think much about access grants.) To implement access grants well, you'll need to think about what groups you'll need, what roles those groups should have, and what account access those groups should have.
If you have a relatively flat organizational structure, and are okay with all or many of your users having wide administrative access and access to all accounts, you'll probably only need at most a few access grants. For example, you might decide to add new access grants to the existing default Admin or User groups, giving those roles access to other accounts. Or, if you need more granular definition over roles and permissions, you'd create access grants that define new groups that have access to specific roles (either our standard roles or custom-defined roles).
Some tips on setting up access grants:
- See the Groups and access grants tutorial.
- To see the UI in action, see our user management videos.
- It may help to first plan out how your access grants will be organized. How many accounts will you have? What user groups will get access to which roles and which accounts? Will you use our default groups and roles or create your own custom groups and roles? Here's a group and access grant planning spreadsheet.
User management terms and definitions
For an explanation of how user access to accounts and roles works, see User access explained. 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 capability is an ability to use or edit a specific, granular New Relic feature. Examples of capabilities:
- The ability to modify APM settings
- The ability to delete alert conditions
- A role is a set of capabilities. It is what gives a user their permissions. Our default standard roles have various capability sets, and you can create custom roles that have a custom set of capabilities. See some specific New Relic capabilities.
- 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 access grant is what grants a user group access to roles and to specific New Relic accounts. An access grant essentially states, "This group is assigned this role on this New Relic account." Adding a user to a group doesn’t do anything unless that group is included in an access grant.
- 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. For example, you may have one authentication domain for users who log in via username/password and another authentication domain for users who log in via SAML.
- If a user is a basic user, this takes precedence over any role-related limitations. For more on this, see Basic user and roles.