--- title: Organization Topology description: >- Choose between single-org and multi-org Datadog deployments, achieve isolation with access controls, and manage multi-org environments. breadcrumbs: Docs > Account Management > Organization Topology --- # Organization Topology ## Overview{% #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{% #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](https://docs.datadoghq.com/account_management/teams.md) and [granular access control](https://docs.datadoghq.com/account_management/rbac/granular_access.md) to satisfy strict compliance requirements. Use a multi-organization topology only when a single organization cannot satisfy a hard requirement. ## Single-organization topology (recommended){% #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{% #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](https://docs.datadoghq.com/account_management/scim.md) 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{% #access-control-within-a-single-organization %} Most organizations can meet their requirements with a single organization's access controls. [RBAC](https://docs.datadoghq.com/account_management/rbac.md), [Data Access Control](https://docs.datadoghq.com/account_management/rbac/data_access.md), [Granular Access Control](https://docs.datadoghq.com/account_management/rbac/granular_access.md), [Teams](https://docs.datadoghq.com/account_management/teams.md), and [IP allowlists](https://docs.datadoghq.com/account_management/org_settings/ip_allowlist.md) enforce strong data segregation within a single organization, even in regulated industries. For detailed implementation guidance, see the [access control documentation](https://docs.datadoghq.com/account_management/rbac.md). ### Limitations{% #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](https://docs.datadoghq.com/account_management/rbac/data_access.md#supported-telemetry) for the full list. ## Multi-organization topology{% #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{% #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](https://docs.datadoghq.com/account_management/org_settings/cross_org_visibility.md) 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{% #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](https://docs.datadoghq.com/account_management/org_settings/cross_org_visibility.md) connects these organizations for operational dashboards without moving raw telemetry across borders. ### Scenario 3: Firewall data between teams{% #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{% #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](https://docs.datadoghq.com/account_management/multi_organization.md) 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](https://docs.datadoghq.com/account_management/org_settings/cross_org_visibility.md). **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{% #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](https://docs.datadoghq.com/account_management/org_settings/cross_org_visibility.md) for immediate operational awareness. The enterprise then executes a phased consolidation over three to six months. ## Decide your topology{% #decide-your-topology %} | Scenario | Organization topology | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------- | | A regulation or contract requires data to exist in a physically separate organization boundary. | Multi-organization | | Cross-region data transfer is prohibited for some of your telemetry. | Multi-organization | | Your security policy requires zero data co-mingling between teams, even with [RBAC](https://docs.datadoghq.com/account_management/rbac.md), [Data Access Control](https://docs.datadoghq.com/account_management/rbac/data_access.md), and [Granular Access Control](https://docs.datadoghq.com/account_management/rbac/granular_access.md) in place. | Multi-organization | | You serve external customers who need separate billing, data, and user pools. | Multi-organization (MSP) | | You're integrating an acquired company that already has its own Datadog organization. | Temporary multi-organization | | None of the above | Single organization | ### Compare org capabilities{% #compare-org-capabilities %} In the following chart, "no change" indicates that Organization Groups do not introduce new capabilities. | Capability | Single organization | Multi-organization | With Organization Groups | | ------------------------------------ | ------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------ | | End-to-end distributed traces | Full | Cannot cross organization boundaries | No change | | Telemetry data | Full | Share metrics, logs, and CI data into dashboards with [Cross-Organization Visibility](https://docs.datadoghq.com/account_management/org_settings/cross_org_visibility.md) | No change | | Dashboards (metrics, logs, traces) | Full | Share [invite-only shared dashboards](https://docs.datadoghq.com/dashboards/sharing/shared_dashboards.md#invite-only-shared-dashboards) with members of another organization | No change | | Monitor alerting across data sources | Full | No cross-organization monitor evaluation | No change | | SLOs across services | Full | Cannot span organizations | No change | | User management | One integration | Separate [SCIM](https://docs.datadoghq.com/account_management/scim.md) per organization | Centralized from group | | RBAC and custom roles | One configuration | Must duplicate per organization | Centralized from group | | SSO / SAML | One config ([multi-SAML](https://docs.datadoghq.com/account_management/saml.md) supports multiple IdPs) | Separate SAML per organization | Centralized from group | | Billing and usage | Usage attribution per organization | Datadog aggregates usage across all child organizations and bills it at the parent organization level | No change | | Feature rollout | Immediate | Must enable per organization | Centralized from group | If your use case requires multi-organization, see [Organization Groups](https://docs.datadoghq.com/account_management/organization_groups.md) for centralized governance across organizations. ## Further reading{% #further-reading %} - [Managing Multiple-Organization Accounts](https://docs.datadoghq.com/account_management/multi_organization.md) - [Organization Groups](https://docs.datadoghq.com/account_management/organization_groups.md) - [Cross-Organization Visibility](https://docs.datadoghq.com/account_management/org_settings/cross_org_visibility.md) - [Role Based Access Control (RBAC)](https://docs.datadoghq.com/account_management/rbac.md) - [Data Access Control](https://docs.datadoghq.com/account_management/rbac/data_access.md) - [Granular Access Control](https://docs.datadoghq.com/account_management/rbac/granular_access.md) - [Teams](https://docs.datadoghq.com/account_management/teams.md) - [SAML Single Sign-On](https://docs.datadoghq.com/account_management/saml.md)