New Relic Organizations are not just a billing boundary; they are the primary mechanism for controlling data access and user permissions across your entire observability platform.
Let’s see this in action. Imagine you’re setting up New Relic for a growing company with distinct engineering teams: a backend services team, a frontend team, and an SRE team.
First, you create a top-level Organization. This is your root container.
{
"name": "MyAwesomeCompany",
"id": "org-12345"
}
Within this Organization, you create separate Accounts. Each Account will house a specific team’s data and users.
Account 1: Backend Services
{
"name": "Backend Services",
"id": "acc-abcde",
"organizationId": "org-12345"
}
Account 2: Frontend Web
{
"name": "Frontend Web",
"id": "acc-fghij",
"organizationId": "org-12345"
}
Account 3: Site Reliability Engineering
{
"name": "SRE",
"id": "acc-klmno",
"organizationId": "org-12345"
}
Now, you invite users and assign them to specific Accounts. A backend engineer might only get access to the "Backend Services" account, meaning they can only see metrics, traces, and logs from their services.
{
"userEmail": "backend.dev@example.com",
"role": "User",
"accountId": "acc-abcde"
}
An SRE might need broader access, perhaps to all accounts, or specific ones relevant to production stability.
{
"userEmail": "sre.lead@example.com",
"role": "Admin",
"accountId": "acc-klmno"
}
This granular control is the core problem Organizations and Accounts solve. Without them, every user would see every piece of data, leading to information overload, potential security risks, and an inability to delegate ownership of observability data.
Internally, New Relic uses these boundaries to scope queries and enforce permissions. When a user logs in and selects an Account, New Relic filters all data retrieval and API calls to only include data associated with that Account. Users are effectively siloed within their assigned Account’s data plane.
The exact levers you control are:
- Organization: The highest level, often representing your company. You can have multiple Organizations if you manage entirely separate entities.
- Account: The primary data and user segmentation unit. This is where you’ll group related services or teams. You can have many Accounts within an Organization.
- User Roles: Define what users can do within an Account (e.g.,
User,Admin,Billing Account Manager). - User Groups: A powerful feature to manage permissions for multiple users simultaneously by assigning roles to groups.
A common misconception is that you must put every microservice into its own Account. This is rarely optimal. Instead, group services by team, by application tier (e.g., "Web Apps," "Databases"), or by business domain. The goal is to align your observability structure with your organizational structure and responsibilities.
When you set up data ingestion (e.g., with the New Relic agent), you specify the Account ID where that data should land. This is crucial: if you deploy an agent and point it to the wrong Account ID, the data will end up in the wrong place, and your teams won’t see their metrics.
# Example agent configuration snippet
NEW_RELIC_ACCOUNT_ID=acc-abcde
NEW_RELIC_LICENSE_KEY=your_license_key_here
The true power of this structure becomes apparent when you start using features like Distributed Tracing. A trace spans multiple services, and if those services reside in different Accounts within the same Organization, New Relic can still correlate them, allowing you to visualize the entire request flow. However, if they are in different Organizations, that correlation is lost.
The next hurdle is understanding how to effectively leverage New Relic’s tagging strategy to further segment and filter data within an Account, complementing the organizational structure.