Overview

Your Datadog organization topology (single-organization or multi-organization) shapes how you observe services, control access, manage users, and attribute cost.

This page covers:

• The capabilities of a single-organization topology
• The scenarios that justify a multi-organization topology
• How to decide which topology fits your needs

Start with a single organization

Datadog recommends a single-organization topology for most deployments. You can manage a single organization by customizing the level of access to your Datadog resources. For example, large enterprises with thousands of users and multiple business units can use Teams and granular access control to satisfy strict compliance requirements.

Use a multi-organization topology only when a single organization cannot satisfy a hard requirement.

Single-organization topology (recommended)

In a single-organization topology, business units, teams, and environments share one organization. Tag-based conventions (team:, env:, service:, cost_center:) drive access policies, dashboards, and billing attribution. Access controls enforce isolation between groups when needed.

Capabilities of a single-org topology

A single organization gives you:

• Connected observability: Distributed traces flow end-to-end across services without gaps. Correlated views across metrics, logs, and traces work without additional customization.
• One configuration surface: Monitors, dashboards, pipelines, and SLOs live in one place, with no duplication and no drift.
• Centralized user management: You only need one SSO configuration, one SCIM integration, and one set of roles and teams.
• Per-team cost visibility: Usage attribution breaks down spend by team, service, or business unit using tags, so you don’t need separate organizations for separate billing views.
• Low operational cost: A single organization doesn’t require Terraform modules per organization, cross-organization workarounds, or duplicated alert routing.

Example: A large technology company with 5,000 Datadog users across 12 business units uses one organization. Each business unit has a Team with discretionary access control restrictions on its telemetry. Platform admins have a global role. Business unit engineers see only their team’s data.

Access control within a single organization

Most organizations can meet their requirements with a single organization’s access controls. RBAC, Data Access Control, Granular Access Control, Teams, and IP allowlists enforce strong data segregation within a single organization, even in regulated industries.

For detailed implementation guidance, see the access control documentation.

Limitations

All users within an organization can see core functionality such as infrastructure. Not all telemetry types support row-level restriction. See supported telemetry types for the full list.

Multi-organization topology

Use multi-organization when a single organization with access controls cannot satisfy a hard requirement, or when separate billing entities require independent invoicing. The following five scenarios qualify.

Scenario 1: Regulatory or contractual data isolation

Would co-locating this data in the same organization violate a regulation or contract, even with team-based access restrictions?

Some regulations require that data never coexist in the same logical boundary. The requirement is not that users cannot see the data, but that the data cannot share the same organization. If your compliance team or external auditors require physical organization-level separation (not row-level restrictions), multi-organization is the right choice.

Use multiple organizations: one per regulated workload, one per required region (for example, a European region), and one for everything else. Cross-Organization Visibility connects the organizations for operational dashboards using consolidated metrics. The regulated organization has stricter access policies, IP allowlists, and audit controls.

Example: A financial services firm separates its trading platform telemetry (subject to SEC/FINRA data handling requirements) into a dedicated organization. All other business units share the primary organization.

Scenario 2: Meet data residency requirements

Is cross-region data transfer prohibited for this data?

When regulations prohibit telemetry from leaving a geographic region, you need organizations in different Datadog sites (for example, US1, EU1, AP1). Cross-Organization Visibility connects these organizations for operational dashboards without moving raw telemetry across borders.

Scenario 3: Firewall data between teams

Is it a risk if one team sees any trace of another team’s data?

Datadog access controls restrict the most common sources of sensitive data. They do not support complete firewalled separation of all telemetry data or asset metadata. If your requirements demand zero data co-mingling, use separate organizations.

Scenario 4: Isolate MSP customers

Do you need separate billing, data boundaries, and user pools per customer?

Managed service providers (MSPs) serving multiple external customers typically need each customer in an isolated organization with independent billing, data, and user management. Datadog’s parent-child organization model supports this pattern.

Use a parent organization for the MSP’s internal operations, with child organizations per customer. Each child organization has isolated data, users, and billing. The parent organization provides centralized operational views through Cross-Organization Visibility.

Example: A managed infrastructure provider with 200+ customers creates a child organization per customer. The parent organization’s NOC team monitors service health across all customer organizations with cross-organization dashboards.

Scenario 5: Integrate an acquired company

Are you integrating an acquired company that already has its own Datadog organization?

Mergers and acquisitions often create temporary multi-organization states. The acquired company’s organization remains active during integration while you prepare the target organization with appropriate access controls, teams, and configurations. The goal is consolidation into a single organization after access controls and migration tooling are in place. For consolidation guidance, contact your account team.

Example: After acquiring a SaaS company, an enterprise connects both organizations with Cross-Organization Visibility for immediate operational awareness. The enterprise then executes a phased consolidation over three to six months.

Decide your topology

Compare org capabilities

In the following chart, “no change” indicates that Organization Groups do not introduce new capabilities.

If your use case requires multi-organization, see Organization Groups for centralized governance across organizations.

Further reading

Additional helpful documentation, links, and articles:

Managing Multiple-Organization AccountsDOCUMENTATION Organization GroupsDOCUMENTATION Cross-Organization VisibilityDOCUMENTATION Role Based Access Control (RBAC)DOCUMENTATION Data Access ControlDOCUMENTATION Granular Access ControlDOCUMENTATION TeamsDOCUMENTATION SAML Single Sign-OnDOCUMENTATION