Here we'll explain how New Relic users get access to specific capabilities and specific accounts.
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 by applying them to a user group.
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.
In order for a New Relic user to be able to access New Relic features, they must be in a group and that group must have access to:
Organizations with Pro or Enterprise edition can have multiple accounts in their organization, and can create custom roles and groups. Standard edition organizations are only allowed a single account in their organization, and don't have the ability to 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 role assignments that give users in that group broad New Relic access, including to the higher level administrative capabilities.
A view of the Access management UI, showing how our default groups (Admin and User) are granted access to roles, accounts, and administrative settings.
Here's a diagram showing how group access works and how they relate to the broader organization:
A diagram showing how groups give users in that group access to roles and accounts.
Here are some resources to help you create or edit group access:
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 grant a role and an account to that group.
A New Relic user must be in at least one group with access to a role and at least one account.
Note 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.
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 any administration settings, which give access to the higher level account and user management capabilities.
- Admin: has all capabilities, including the higher-level administration settings. This is the equivalent of having the standard role of All product admin with all available administration settings.
To change a user's group, use the User management UI.
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.
We have several "standard roles," which are roles that are available by default and that satisfy some commonly needed sets of capabilities.
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.
User type guidelines
All product admin
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.
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.
Provides read-only access to the New Relic platform (except for synthetic monitor secure credentials).
Manage v1 users
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.
When you create or edit a group, you can add Administration settings that control access to various organization-scoped capabilities.
In August of 2022, we removed some organization-scoped roles and replaced them with similarly named Administration settings. If you had these roles assigned to groups, they've been converted to the equivalent settings.
Administration settings require you to have a user type of core or full platform. A group can't have only an administration setting assigned: the group must have at least one account assigned.
- Organization settings: Provides capabilities related to organization settings, including adding accounts, changing the name of the organization and accounts, and some other organization settings.
- Authentication domain settings: Provides capabilities related to adding and managing users, including configuring authentication domains and customizing groups and roles.
- Billing: Lets a user manage subscriptions and billing setup. For organizations with multiple accounts, billing is aggregated in the primary (first-created) account.
For information on the capabilities that roles have and that are available for addition to custom roles, see Capabilities.
To learn how to add users, assign them to groups, and create custom groups and roles, see Manage users.
Pro and Enterprise edition organizations can create and configure group access. To set up groups optimally, 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 extra group configurations. For example, you might decide to add more accounts to the existing default Admin or User groups. Or, if you need more granular definition over roles and permissions, you'd create new groups with access to specific roles (either our standard roles or custom-defined roles).
Some tips on customizing group access:
- See the Tutorial on user management.
- To see the UI in action, see our user management videos.
- It can help to plan out how your groups will be organized. Here's a group access planning spreadsheet. The kinds of question you may want to answer are: 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?
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 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 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.