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 factors:
- A user's 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 overrides all role-related access. It's meant to be a fairly long-term setting based on someone's expected New Relic duties.
- A user's assigned roles: 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.
Let's say a basic user is assigned a group with a role with wide New Relic access, like All product admin. That user's user type (basic user) takes precedence, and would prevent them from using some of the features that a core user or full platform user would have access to.
This doc is focused on role-related permissions. For details about user types, see User type.
In order for a New Relic user to use New Relic features, they must be in a group with assigned 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.
We offer several default roles, but organizations with Pro or Enterprise edition can create their own custom roles.
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 adminrole in an account, and in another group that gives you a
Read onlyrole for the same account, you have both roles, and are not restricted by the
- A user's user type overrides role-related access.
- Roles govern observability platform features, while access to organization- and user-related admin settings are governed by administration settings.
To view roles and their capabilities, go to the Access management UI and click 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 replaced some organization-scoped roles 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.
- 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 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).
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.