Groups

Groups form the foundation of access control in ONE.

They organize users into teams and help determine:

How access is shared and inherited.
Who can see what across your data assets.
How sensitive data stays protected.

What groups are for

Groups serve two main purposes:

Organize users by how they work with data. Groups don’t have to mirror your organizational chart. Instead, use groups to reflect who needs access to the same data.

For example, everyone who works with financial data might belong to a "Finance Data" group, regardless of whether they’re in accounting, sales, or compliance.
Facilitate how access flows. When you share an asset or assign stewardship to a group, all members receive access. The group hierarchy determines who can see what and helps you restrict access to sensitive data.

Why hierarchy matters

The hierarchy controls two key behaviors:

Inheritance (top-down): When you share an asset with a parent group, all child groups automatically receive access.

Example: If you share a set of business terms with the "Organization" group, everyone in the company can see them.
Oversight (bottom-up): Users in a parent group can see all assets shared with their child groups.

Example: If your "Data Governance" group is the parent of "DQ Team" and "Stewardship Team," members of Data Governance can see assets shared with either child group.

How to design your hierarchy

When designing your group hierarchy, think about how your teams work with data and which data needs protection.

Your organizational chart might be a useful starting point, but reporting structures rarely translate well to access control, especially in federated organizations where teams and responsibilities shift frequently.

For examples of group structures based on organization size and governance maturity, see Access Management Models.

Instead, consider:

Who needs access to the same assets? Group these users together.
Who needs oversight? Make them a parent group.
What’s the scope of responsibility? Teams with broader responsibility sit higher in the hierarchy.
What data is sensitive? Ensure it’s only accessible to groups that need it.

Here is an example structure for a data governance organization:

Organization
├── Data Governance
│   ├── DQ Team
│   └── Stewardship Team
├── Analytics
│   ├── Finance Analytics
│   └── Marketing Analytics
└── Engineering
├── Data Engineering
└── Platform Team

Group isolation

By default, members of a group can share assets and assign stewardship to any group they can see. Group isolation restricts this.

When a group (or branch) is isolated:

Members can only share assets within their own group or branch.
Members can only assign stewardship within their own group or branch.
The oversight mechanism still applies, with parent groups retaining visibility.

Isolation is useful when:

Different business units must keep data separate due to regulatory requirements or competitive boundaries.
You want to prevent accidental sharing outside a team’s scope.
Regional or departmental data should stay contained.

Isolation doesn’t affect users outside the isolated branch. Users from parent groups or other branches can still share assets with the isolated group if they have appropriate permissions.

Likewise, if access was shared with users before the group became isolated, these users retain their access until manually revoked.

Best practices for creating groups

Inheritance and oversight in root group

Avoid adding users directly to the root group. Due to oversight, adding users directly to the root group in the hierarchy (such as "Organization") would result in all users seeing all assets shared with any other group.

Instead, create appropriate child groups and add users there.

Use the root group for company-wide sharing. Thanks to inheritance, when you need everyone to access something (like approved business terms), share it with your root group. Access will be inherited by all child groups.

Design for data access

Create groups based on data access needs, not organizational structure.

A user can belong to multiple groups, so focus on what data they need rather than where they sit in your company. For example, someone in Marketing who also works on a cross-functional data project can be in both "Marketing Analytics" and a project-specific group.

Start simple, protect what matters

A flat structure with a few groups is easier to manage than a deeply nested one you don’t need.

Focus first on ensuring sensitive data is appropriately protected. You can always add child groups later as needs become clearer.

Use exceptions sparingly

Prefer sharing access with groups rather than individual users. While adding a specific user might be a quick fix, it creates exceptions that are harder to audit and can lead to issues later. For example, a user could accidentally retain access even after their responsibilities have changed.

Similarly, use group isolation only when you have a clear need (regulatory separation, preventing accidental sharing). Isolation solves real problems but adds complexity.

Governance roles within groups

Each user in a group is assigned a governance role that determines what they can do with assets the group has access to.

The same user can have different roles in different groups: for example, a Data Owner in one group but only a Data Consumer in another. For more information, see Governance Roles.

Was this page useful?