Tutorial on managing accounts and users

This tutorial will walk you through adding and managing accounts and users.

Before you start

Before you start this tutorial, some things to understand:

Pro or Enterprise edition is required (Standard edition can't add accounts or access grants)
This tutorial is for managing users who are on our newer user model.
This tutorial will be easier if you first have a basic understanding of:
- Organization and account concepts
- User management concepts
This tutorial won't show you all user management functionality. For more complete docs, review the user management docs.
This tutorial presents one recommended workflow but there are many ways to do these steps and no particular order of steps is necessary.
For an example spreadsheet showing how one might plan out your users' roles and account access, see the Access grant planning spreadsheet.

Overview

This tutorial will walk you through:

Organization creation
How to add accounts
How to set up an authentication domain
How to set up custom roles
How to set up access grants (give groups access to roles and accounts)
How to add users

Step 1: Organization creation

If you're reading this, you likely already have a New Relic organization. When you sign up for New Relic, your New Relic organization is created. The organization structure represents a New Relic customer: it's what contains everything relevant to a customer's use of New Relic: their accounts, their users, and their data.

When a New Relic organization is created, it contains a single account. A Standard edition organization can only have a single account, but Pro and Enterprise edition organizations can add more accounts. Each account has its own account ID, and that ID is used for some account-specific tasks, like making API calls.

When your organization is created, it has several default access grants, which grant the two available default groups access to specific roles, and a specific scope of accounts. When you add users via the UI, there are two default groups that you can assign your users to:

Admin: can use and configure observability features for that initial account, and the ability to view and configure organization-level settings (like adding accounts or managing users).
User: can use and configure observability features, without the higher level organization capabilities.

You can see the default access grants created for these groups by going to the Access management UI:

You can see how the User group has the All product admin role and access to that initially created account. And you can see how the Admin group has four access grants, reflecting its greater capabilities. The "Default" next to those group names refers to them being in the original, default authentication domain (we'll talk more about that later).

Pro and Enterprise edition organizations are able to add custom groups, or bring in groups from their identity provider.

Step 2: Add accounts

Before adding your users in New Relic, you might want to get some data reporting and set up additional accounts. This isn't required at this point: you can always set up accounts and get data reporting later, and adjust your users' access after that.

For guidance on why an organization should create more accounts, see Organization structure.

If you did want to create accounts at this point, see Add accounts.

Step 3: Set up authentication domains

When your organization is first created, the groups and users are located in a default authentication domain, named "Default." An "authentication domain" is a grouping of New Relic users governed by the same user management settings, like how they're provisioned (added and updated), how they're authenticated (logged in), session settings, and how user upgrades are handled.

The default authentication settings are:

Users are manually added and managed via the New Relic UI
Users manually log in to New Relic using their email and password

Having that one authentication domain might be fine for many organizations, but some organizations want one or both of the following:

Single sign-on (SAML SSO)
Managing their users from their identity provider via SCIM provisioning

And if they want those things, they'll have to create an additional authentication domain. Note that groups and users are contained within authentication domains, and you can't easily change an authentication domain's provisioning setting or authentication setting once the domain is created: this means you should spend some time thinking about what your authentication domain settings should be before you add users to them.

If you're okay with the default authentication domain (managing your users from New Relic, with your users logging in with their email and password), you can skip to Step #4. If you want to use SAML SSO or SCIM provisioning, see these options:

Step 4. Create custom roles (optional)

We have default-available roles (standard roles), so creating custom roles is optional. If you don't have a need for custom roles, you can skip this step.

Some tips to help you understand what roles are:

Users are assigned to groups (for example, the default Admin and User groups), and those groups are assigned various roles and accounts via what we call "access grants." Put another way: it's not the group that gives users access to New Relic capabilities: it's the roles.
A role contains various capabilities. For example: the capability to create and modify alert conditions, or the capability to delete data ingest license keys (for more information, see Capabilities.)
Unlike groups and users, roles are not contained in an authentication domain: they're available across the entire organization.
We have several default-available roles, which we call standard roles. Some of these are assigned to the Admin and User groups that are available by default. If your organization is Pro or Enterprise edition, you can create your own custom roles.

For an example spreadsheet showing how one might plan out roles and groups and access grants, see this Access grant planning spreadsheet.

To view existing roles: from the account dropdown, click Administration, then click Access management, and then click Roles.

To create a custom role, click Add new custom role. Review the list of available capabilities and decide which ones your custom role needs.

Here's a short NerdByte video showing how to create a custom role (4:07 minutes):

For more information about how roles and capabilities work, see Capabilities.

Step 5. Create groups and access grants

Groups are used to group your users and manage what your users are able to do in New Relic: by creating an access grant, you assign a group access to a specific role and an account scope (a specific account or a role with organization-wide capabilities).

For an example spreadsheet showing how one might plan out roles and groups and access grants, see the Access grant planning spreadsheet.

To view existing access grants: from the account dropdown, click Administration, and then click Access management. Even if you haven't created any access grants, you'll see the default-created groups and their access grants. (For more on this, go back to Step #1).

If your organization has multiple accounts, or if you're using SCIM provisioning, you'll need to add custom access grants.

You can manage groups and access grants via either the UI or via API:

Before creating access grants, ensure you have a good understanding of the user management concepts and have a good plan for the access grants you want to create. It may help to map out the groups, roles, and accounts you want users to have access to in a spreadsheet beforehand.

To create access grants from the UI:

From the Access management UI, click Access grants and groups.
Choose one of the following:

Existing: If there is already a group you want to add an access grant to, you can use this. For example, if you want to gives users in the default Admin or User group access to new accounts, you might choose this and then select the Admin Default or Admin User role.
New: If you need to create a new group, choose this. (This is not available for SCIM provisioning because your groups are managed via SCIM.)

Next, under Access grant, you'll choose one of following:

Account: Choose this to be able to select from the roles that are account-scoped. These are the roles that have to do with using and configuring our observability features (and not about organization and user management).
Organization: Choose this to be able to select from the roles that are organization-scoped. These are the roles that govern organization- and user management. (Note that these users must also already belong to an account-scoped role. This is true for most users but if it's not, you may see a message that the user doesn't belong to an organization.)

Select the Role you want to assign. For tips on selecting roles, see the tips at the end of this procedure.
Select the Account you want to add access to from the dropdown. If you don't see an account that you'd expect to see, this may be for a few reasons. One is that you yourself don't have the proper permissions for that account. Another is that that account is not actually in your organization. For more information, see Factors affecting access. If you are still having problems, talk to your account representative.
If you want to continue adding more grants for that same group, select Add another at the bottom before clicking Add access.
When you're done, if users are already in a group you've added a grant to, they'll have access within a few minutes (although for EU region organizations, this can take up to twenty minutes or so). If your users are not yet in that group (which would be true if you just created an access grant with a new group), the next step will show you how to add users.

Some tips for using this UI:

Note that if a user is assigned the organization-scoped Organization manager and/or Authentication domain manager roles (which is true of users in our default Admin group) those users have them across the organization. In other words, once the users in a group have those organization-scoped roles, they will always have them for that organization unless removed. This means that when you go to add those users to another account, you only have to add an account-scoped role, and not an organization-scoped role.
When selecting from amongst our standard roles, it's important to understand the difference between All product admin and Standard user. In short, All product admin is more popular a choice because it gives the ability to configure platform features. If you wanted to have your users be able to use platform features but not configure them, you'd choose Standard user.

Step 6. Add users

If you're using SCIM provisioning, you should be done at this point because your groups and users are imported from your identity provider. You can move to the verification step.

Otherwise, you'll need to add users. In the user management UI, you can see your users and the groups they've been assigned to.

Suggested steps for adding users:

To view users and see their groups: from the account dropdown, click Administration, and click User management.
Optional: select your authentication domain using the switcher in the top left. (Remember that groups reside within the boundaries of an authentication domain).
To add a user, click Add user. Complete the prompts in the UI, including choosing the user type and group. Any custom groups you’ve added should be available from the group dropdown. If the custom group you choose has had an access grant created for it, once you add the user to that group, that user will have access.

To edit a user's group or other details: click on the user you want to edit and make changes. For tips on bulk editing and other common tasks, see Common user management tasks.

Once your users are added, remember that you have the option of using our API to add and remove users from groups: see NerdGraph user management.

Step 7. Verify things are working

Ideas for checking that your users are configured correctly:

Go to the User management UI and Access management UI and see if the groups and grants assignments look correct and make sense.
Have some of your users see if they can log in and access the accounts they expect to see.

Ideas for next steps:

Set up more New Relic integrations
Add more users