Clarification on Collection and Sub Collections Hierarchy Limits along with Root in Microsoft Purview

Hi SudhakarReddy Marepalli,
Thank you for reaching out microsoft Q&A! with your questions regarding collection hierarchy limits and governance design in Microsoft Purview. I’m happy to provide clarification on the current platform capabilities and recommended practices.

In Microsoft Purview, every account starts with a Root Collection, and all other collections are created beneath this root. Currently, Microsoft Purview does not enforce a strict documented limit on the total number of collections that can exist within a single Purview account, including top-level collections under the root. Organizations commonly create domain-based collections such as Claims, Billing, Policies, Reporting, and similar business units under the root to represent governance domains.

There is also no explicitly enforced hard limit on the number of sub-collections that can be created under a parent collection. Sub-collections are typically used to further segment governance responsibilities, environments, or data domains, such as separating Production, Development, and Test environments or grouping different data platforms.

Regarding hierarchy depth, Purview supports multiple nested levels of collections. However, Microsoft generally recommends keeping the hierarchy reasonably shallow, commonly around three to five levels, to make governance and permission management easier. Very deep hierarchies can become more complex to manage from an administrative and operational standpoint.

From a design perspective, it is recommended to structure collections based on data ownership, business domains, or organizational structure. A common enterprise model starts with the Root collection, followed by business domains such as Claims, Billing, or Policies, then platform or environment levels such as Azure, SQL, ADLS, or Dev/Test/Prod, and finally the individual data sources or team ownership level. This approach helps ensure that role assignments, scanning responsibilities, and governance controls can be delegated effectively.

From a performance perspective, Microsoft Purview is built to support large enterprise environments and a significant number of collections. However, when a hierarchy becomes very deep or when governance structures become overly complex, administrative overhead can increase, particularly when managing permissions, scan configurations, and governance responsibilities. For this reason, maintaining a clear domain-based structure with moderate hierarchy depth is considered a best practice.

Purview collections are designed to be flexible and scalable. The key design consideration should focus on clear ownership boundaries, manageable hierarchy depth, and effective governance delegation rather than strict platform limits. Your proposed approach of organizing collections under the root based on business domains with sub-collections for further segmentation aligns well with typical enterprise Purview governance models.

Please feel free to reach out if you would like additional guidance on recommended enterprise collection design patterns in Microsoft Purview.

Within the provided context, Microsoft Purview collections and hierarchy limits and behaviors are as follows:

1. Maximum number of collections per Microsoft Purview account

• A Microsoft Purview account can have up to 1000 collections in total in its collections hierarchy.
• This 1000‑collection limit applies across the account’s hierarchy (not per branch).
• Separately, governance domain guidance states: “Collections are limited to 1000 across all platform domains.” For example, if using all 5 domains, that could be ~200 collections per domain if distributed evenly.

2. Limit on number of sub‑collections under a parent

• A collection can have as many child collections as needed; there is no explicit per‑parent child count limit in the context.
• Constraint is at the total collections (1000) and hierarchy depth levels, not at “children per parent.”

3. Maximum depth of the collection hierarchy

• A collections hierarchy can support up to eight levels of depth, excluding the root collection.
• The root collection is created automatically with the account and sits above these eight levels.

4. Key structural rules and constraints

• Each collection:
  • Can have only one parent collection.
  • Can be associated with only one domain.
• Data sources:
  • Are registered in one collection in one domain.
  • Cannot be registered multiple times in a single Purview account.
  • Assets from a scanned data source must be scanned in the same domain as the data source.
• Scans:
  • By default run in the same collection as the data source, but can optionally be run in a subcollection, so assets appear under that subcollection.
• Deletion and movement:
  • A domain can be deleted only if it is empty.
  • A collection can be deleted only if it has no assets, scans, data sources, or child collections.
  • Moving data sources across collections is allowed if the user has Data Source Admin on both source and destination collections.

5. Best‑practice guidance for hierarchy design From the provided guidance and examples:

• Use collections to mirror organizational or sub‑organizational structure (for example, regions → departments → subdepartments) so that access control and ownership follow business lines.
• Treat collections as both:
  • Organizational “bins” for data sources, scans, and assets.
  • Security boundaries for metadata, implementing least‑privilege access (users see only what they need).
• Recommended pattern for a federated catalog:
  • Do not use the account root collection directly for day‑to‑day organization.
  • Create a top‑level “federated metadata catalog” collection under the root.
  • Assign a broad Data Reader group at this federated‑catalog level so read permissions propagate to child collections by default.
  • Allow divisions or business units (for example, Claims, Billing, Policies, Reporting) to have their own subcollections where they can:
    • Register data sources and run scans.
    • Create further subcollections for teams or domains.
    • Break inheritance where stricter isolation is required (for example, highly sensitive subdepartments) using restrict inherited permissions.
• Plan domains and collections together:
  • Domains are limited to 5 total and are used to separate certain resource types (credentials, policies, custom scan rules, etc.).
  • Collections sit under domains and are where data sources, scans, and assets are organized.
  • Given the 1000‑collection and 5‑domain limits, design a structure that can scale across business units without exceeding these caps.

6. Performance and operational considerations (from constraints and guidance)

• The explicit platform limits (1000 collections, 8 levels deep) are set to keep the hierarchy manageable and performant.
• Recommended practices to avoid operational complexity:
  • Avoid using the root collection as a working container; instead, use it only as a technical root and create a small number of top‑level collections (for example, a federated catalog or major divisions).
  • Keep hierarchy depth meaningful; use the 8‑level limit to structure by major dimensions (region → business unit → department → team, etc.) rather than very fine‑grained nesting.
  • Use inheritance for permissions wherever possible and only break inheritance for collections that require strict isolation, to reduce administrative overhead.

Applied to the example (Claims, Billing, Policies, Reporting):

• Place these as first‑ or second‑level collections under a top‑level “Federated Catalog” or “Enterprise Data” collection.
• Under each (for example, Claims), create subcollections for subdomains (for example, Claims/Operational, Claims/Analytics, Claims/Regulatory) and further subcollections for teams or projects, staying within the 8‑level depth.
• Ensure total collections across all business units remain within the 1000‑collection limit and that data sources are registered once in an appropriate collection/domain, with scans and assets organized via subcollections as needed.

References:

• Microsoft Purview domains and collections architectures and best practices
• Governance domains and domain recommendations
• Collections
• Create and manage collections in Microsoft Purview Data Map (classic)
• Access control in the classic Microsoft Purview governance portal
• Design a collection structure for a Microsoft Purview federated catalog