Understanding the structure of New Relic organizations and accounts will help you with finding data in New Relic and setting up user access.
Organizations and accounts
At New Relic, an organization represents a New Relic customer. Your New Relic organization contains everything relevant to you and your team members: your organization's accounts, users, and data.
When you sign up for New Relic, this creates an organization containing a single account. Our Free and Standard editions can have only a single account. Pro and Enterprise edition organizations can add accounts.
An account can have many sources of data reporting to it. For example, a single account could have data reporting from our infrastructure agent, an agent, and other integrations. All data reported to New Relic requires an account ID, which tells New Relic which account that data belongs in. That ID is also used for some account-specific tasks, like making API calls.
When you set up user access, you grant users access to specific accounts.
Cross-account access
New Relic provides cross-platform features that let you share data across accounts. For example, you can assign a user to multiple accounts, which shares data from those accounts to the user even if they're not the account owner. Other features like distributed tracing, custom , and workloads share data from entities monitored in other accounts, so long as you're assigned access to those accounts.
But there are some cross-account boundaries. For example, the query builder only lets you query in the account you're currently in (to make a cross-account query, you'd have to use our NerdGraph API). This is one reason you might choose to try to minimize the number of accounts you have. Another limitation to keep in mind is that you cannot create cross-account alerting. This can cause complications if you need to aggregate data across multiple accounts.
Reasons to add accounts
Why you'd add more accounts depends on your goals and structure. Some reasons to add accounts include:
- To separate production and testing environments. For example, you might name one account
Invoice processing dev
and anotherInvoice processing prod
. - To make it easier to separate billing for different departments.
- To separate projects of any sort that have fairly distinct datasets.
- To control user access to different projects or data sets for security purposes. For example, you might want to set up an account for outside contractors, which only contains data from certain entities, to limit what that group has access to.
For how to add and rename accounts, see Add accounts.
How users access accounts
In your organization, your New Relic users are granted access to specific accounts that are relevant to their duties and responsibilities. To manage users' access to accounts, you grant groups access to specific roles on specific accounts. Our user management system allows you to create the user access you need, whether that's a relatively simple setup with just a few roles across a few accounts, or a complex one with many roles across many accounts. Learn more about user management.
Note that some features, like and workloads, can display data from across different accounts in an organization. This means that if a user isn't granted access to all relevant accounts, they may experience missing data.
To learn more about access issues, see Factors affecting access.
Original user model
If your users are still on our original user model, the account structure and access works differently: see Original user model account access.