Here we'll explain how New Relic users get access to specific capabilities and specific accounts.
How user access works: user type and roles
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's meant to be a long-term setting based on someone's expected New Relic duties over the next few months or years.
- 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 settings). Roles are assigned by applying them to a user group.
How user type and role access intersect
A New Relic user is given permission to use a New Relic feature by the combination of their a) user type, and their b) role permissions. Put another way: for a New Relic user to access something, neither the user type nor any assigned roles must restrict that.
For example, let's say a basic user is assigned a role with a lot of New Relic access, like All product admin. Their user type (basic user) would prevent them from using many of the features that a core user or full platform user can access. In order to get more access, they'd have to upgrade to a core or full platform user.
As another example: let's say a full platform user has a restrictive role assigned (like Read only). A full platform user can theoretically access all of New Relic, but in this case their assigned role would restrict their access. To get more access, their assigned roles would need to be changed (for example, by assigning them to a different group, or adjusting the roles assigned to their group).
The rest of this doc is focused on roles and groups. For more on user type, see User type.
Groups give users access to roles and accounts
In order for a New Relic user to use New Relic features, they must be in a group with assigned access to:
- A specific role (a role being a set of specific, granular capabilities).
- One or more accounts.
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:
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 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 that group that grant access to New Relic capabilities.
We have two simple user groups available by default (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 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, but doesn't have any administration settings, which grant access to the higher level account and user management capabilities.
- Admin: has the All product admin role and in addition has all available administration settings. In effect, this default group has access to all features, including the higher-level admin features.
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.
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.
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 settings), but it doesn't provide organization-level admin capabilities (those require the administration settings).
This role is essentially the Standard user role, below, with the added ability to configure observability features.
Any. Recommended: core or full platform.
Provides access to our platform features (for example, 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.
Tips for setting up group access
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?
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 capability is an ability to use or edit a specific, granular New Relic feature. Examples of capabilities:
- The ability to modify 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.