Important user 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, and that's what the remainder of this doc is about.

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, see User type and roles. The remainder of this doc is about role-based access.

How groups and roles control access to New Relic

At New Relic, user groups contain roles, and those roles contain permissions. 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 permissions).
• One or more accounts.

Organizations with Pro or Enterprise editions can have multiple accounts in their organization, and can create custom roles and groups. 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 role assignments that give users in that group broad New Relic access, including to the higher level administrative permissions.

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

For tips on setting up groups, 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 (see below). 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. 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.

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.
• A user's access is based on the access granted to them by their user type and their permissions (learn more).
• Roles govern observability platform features, while access to organization- and user-related admin settings are governed by administration settings.

To view roles and their permissions, 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 common user management use cases.

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

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

Administration settings

You can add various Administration settings to a group. Basic users will not be able to use these settings.

Settings include:

• Organization settings: Permissions related to organization settings, including adding accounts, and changing the name of the organization and accounts.
• Authentication domain settings: 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 mgmt 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).

Group admin

You can add a Group admin role 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 and organization-scoped Manage authentication domain setting. For example, you may have only one or two admins in the company with the 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 at least one of the authentication domain admin settings.

Capabilities

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 and groups 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.