In this doc you'll learn how we define user type, what features each user type has access to, and how to decide on a user type.
Want to learn about how users are calculated for billing purposes? See New Relic pricing. If you haven't already, be sure to sign up for a New Relic account. It's free, forever.
What is the user type?
A New Relic user's user type determines the maximum set of New Relic permissions they can access. The user type is meant to be a fairly long-term setting based on a user's expected responsibilities over the next several months or longer.
Choosing a user's user type is mainly a billing-related decision. Core users and full platform users are billable, while basic users are not. It is a matter of how much value an organization expects to get out of a team member's use of New Relic. (For details on billing, see User billing.)
User type should not be used as a way to control a user's permissions. This is because New Relic will occasionally adjust the permissions available for each user type. To restrict access to permissions, you should use roles.
There are three user types:
- Basic user: access to several basic but powerful New Relic platform features.
- Core user: access to several more features than a basic user.
- Full platform user: access to all features.
If you're tasked with adding New Relic users, one of the key decisions to make is what user type to make them. If you're not sure at first, you can add them as basic users and later decide which users you want to upgrade. For how to adjust user type, see Manage user type.
Overview of user type access
Here's a brief summary of what each user type gets access to:
Basic user | Core user | Full platform user |
|---|---|---|
Basic users are free. Basic users can set up our observability tools, run queries on your data, use custom (quickstart dashboards up to 7 days), use some basic alerting features, and more. Basic users can't use our curated experiences (for example, our UI, UI, or mobile UI). | Core users can access more features than basic users but less than full platform users. They have access to some powerful developer-centric features like New Relic CodeStream, errors inbox, and our log management UI. | Full platform users can access everything, including our more curated observability UI experiences, such as APM, infrastructure monitoring, browser monitoring, , synthetic monitors, and more. |
For a more detailed comparison, see the User type access comparison table.
How to pick a user type
Before deciding on user types, you'll want to understand the billing impacts and downgrade rules. For an in-depth access comparison, see the User type access comparison table.
Here are some tips for deciding on a user type:
Reasons to make someone a full platform user:
- They need full access to the New Relic platform (our curated dashboards and other experiences), not only the ability to query and create custom charts.
- They play a key role in the development, testing, deployment, and maintenance phases of the application development lifecycle.
- They break/fix code regularly; they are responsible for triaging workflows, troubleshooting, or managing users and roles for their team.
- They have DevOps practices (for example, version control systems, and implementation of CI/CD).
Reasons to make someone a core user:
- They're developers who aren't tasked with reliability and uptime as their main responsibility.
- They don't require full platform access, but would benefit from some of the specific functionalities offered to core users, like:
- Debugging code issues directly from their IDE, using New Relic CodeStream.
- Viewing errors in one place from across your stack, using Errors inbox.
- Using our logs UI to spot problems and patterns in logs.
- The ability to use apps from our New Relic app catalog.
- They need to be able to manage users and/or billing (both core and full platform users can do that).
Reasons to make someone a basic user:
- They don't need full platform access to use our curated experiences and , but would benefit from creating custom queries and charts of data.
- They play a key role in the planning phase of the application development lifecycle.
- They use and configure New Relic tools to get data into New Relic, and access, configure, and use on such data, but are not necessarily responsible for triaging workflows, troubleshooting, or managing users and roles for their team.
- They want to see high-level analytics and business metrics for future planning (as is often true of C-suite executives).
- They don't manage users or billing.
User type access comparison table
Below is a detailed comparison of the features each user type has access to. Important points about this table:
- The table comes from our pricing page. To find the table, visit the User costs heading and click View permissions.
- Many of the features require access to our UI experiences, not to the underlying data. All users can query all data in the accounts they can access and can create and view custom charts. For instance, basic users can access data, browser monitoring data, and more, but can't access curated UI experiences.
- The user type is meant to be a long-term setting. Both user type and roles govern access to New Relic features. Learn more about user access factors.
For tips on why you'd choose one user type versus another, see Decide on user type.
Feature | Basic user permissions | Core user permissions | Full platform user permissions |
|---|---|---|---|
700+ integrations (Instant Observability and quickstarts, except curated views) | |||
Custom charts and dashboards | |||
Custom events | |||
Entity explorer, Lookout, Navigator | List view only | (except deviating signals) | |
GraphQL API (NerdGraph) | |||
In-app collaboration | |||
Log management | Searching/viewing only | ||
Powerful querying capabilities | |||
Quickstart dashboards | Up to 7 days | Up to 7 days | |
Receiving alerts and notifications | |||
Admin settings (managing billing and users) | |||
Building and running custom New Relic apps and visualizations * | |||
Error tracking with errors inbox | Except attributes analysis | ||
New Relic CodeStream IDE extension | |||
AIOps (artificial intelligence for IT operations) | |||
Application performance monitoring (APM) | |||
Browser monitoring | |||
Change tracking | |||
Database monitoring | |||
Distributed tracing | |||
Infrastructure monitoring | |||
Kubernetes monitoring with Pixie * | |||
Machine learning (ML) model performance monitoring (MLOps) | |||
Mobile monitoring | |||
Network monitoring | |||
OpenTelemetry monitoring | |||
Security monitoring (Vulnerability Management) ** | |||
Serverless monitoring | |||
Service and entity maps | |||
Service-level management | |||
Synthetic monitoring | |||
Workloads |
* Subject to additional terms and conditions.
** New Relic Vulnerability Management is included for up to 100 GB of data ingest and requires Data Plus or additional cost beyond that.
Here are additional details about permissions for some features:
Here are more details about how user type impacts access to alerting and applied intelligence features:
What you get | Basic user | Core user | Full platform user |
|---|---|---|---|
Set up alert conditions, correlation decisions, and notifications | |||
Acknowledge and resolve issues | |||
Access to higher-level applied intelligence features, including:
|
Details about access to our APIs:
- Data ingest: All user types can set up almost all of our integrations and agents, including ingesting data via our ingest APIs. Some New Relic solutions require being a full platform user to set up. If so, it is mentioned in the requirements section for the docs of those solutions.
- NerdGraph: A user can use NerdGraph API to do the same things they can do from the UI. For example: configuring settings requires being a full platform user, whether that configuration is done via the UI or via NerdGraph. For another example: the administration-related permissions (for example, adding users, and adding accounts) require being a core user or full platform user, whether that's done in the UI or via NerdGraph.
Error messages about not having permissions when using an API may relate to user type restrictions. For more on access factors, see Factors affecting access.
Details about access to the options available on our Instant Observability page:
- Basic and core users can install almost all New Relic solutions but, as shown in the user type table, they can't access our curated experiences (for example, our APM UI, mobile UI, and infrastructure UI).
- For the custom dashboards that come with our quickstarts (for example, the dashboard included with our .NET quickstart): basic and core users can access those for 7 days.
Details on feature access by user type:
Basic users | Core users and full platform users |
|---|---|
| All features. This includes those in the Basic user column plus the ability to:
These users can also see logs in context for the UI experiences they have access to (for example, core users can see log data in the errors inbox UI). |
User type and roles
Here's an explanation of how user type and role-based access differ:
- A user's user type: What user type to make a user is a question of what an organization expects their team members to do with New Relic, and how much value they expect to get out of that work. It's mainly a billing-related decision. It sets the maximum allowed permissions a user can access. User type is not meant to be used for controlling a user's access and permissions: for that, you should use roles.
- A user's roles: Roles are what control a user's access. Roles are made up of permissions, which grant access to do specific things in New Relic (for example, the ability to modify APM settings). Roles are assigned by applying them to a user group, and can be present on one or more accounts in an organization.
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. For a New Relic user to access something, their user type and the role(s) assigned to them must allow that access.
For example, let's say a basic user has a role with wide New Relic access, like All product admin (which both the default groups User and Admin have). Their user type (basic user) would prevent them from using many of the features that a core user or full platform user with that role can access. In order to get more access, the basic user would have to become a core or full platform user.
As another example: let's say a full platform user has a restrictive role assigned for a specific account (like Read only). A full platform user can theoretically access all of New Relic, but in this case their assigned role for that account greatly restricts 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).
For more about roles and groups, see User management concepts.
Manage user type and upgrade requests
How you manage a user's user type depends on which user model your organization's users are on:
- Docs for our newer user model
- Docs for our original user model
For rules around billing and downgrading users, see Billing and downgrade rules.
Lacking access to something?
For questions related to lack of access to New Relic accounts or features, see Factors affecting access.
