User Community Service Desk Downloads

Access Management Models

How you structure groups and manage access depends on your organization’s size, governance maturity, and how teams work with data. This page describes three common patterns to help you design an approach that fits your needs:

Project-centric model

Best for organizations that use ONE as a tool for specific projects, without a centralized data governance function.

  • Users work alone or in small project teams.

  • Assets are grouped by project and not shared across teams.

  • No central authority manages platform-wide standards.

  • Teams have full control over their own assets.

Example: A data quality team adds a few sources to the catalog, creates DQ rules and monitors, and works independently. No one outside the team needs to see or use their assets.

How to set it up

  • Create a group for each project team.

  • Keep groups flat (minimal hierarchy).

  • Assign stewardship of project assets to the project group.

  • Share assets only within the project team as there’s no need for broad visibility.

Curated model

Best for organizations with a dedicated data governance team that provides standards and shared assets for others to use.

  • A central team (for example, Data Governance, Data Office) defines standards and curates shared assets.

  • Curated assets (rules, terms, validated sources) are shared organization-wide.

  • Other teams use curated assets but might also create project-specific assets.

  • There is clear separation between "official" assets and team-specific work.

Example: The Data Governance team creates official business terms and DQ rules, shared with the entire organization at view data access. The Finance Analytics team uses these shared terms but also creates their own DQ monitors, which only they can see.

How to set it up

  • Create a group for the central governance team with broad visibility.

  • Create groups for each business unit or team that consumes data.

  • The governance team owns curated assets (terms, rules, validated sources) and shares them with the root group at view data access.

  • Business teams own their own project assets and share as needed.

Federated model

Best for large organizations with multiple independent units (business units, regions, subsidiaries) that need separation.

  • Multiple units operate independently with their own data and governance.

  • Units are organized in a hierarchy (for example, global → regional → local).

  • Central oversight exists, but units manage their own assets.

  • Some assets might be shared across units; most stay within unit boundaries.

Example: A global company has regional groups (EMEA, APAC, Americas) with country-level groups beneath them.

  • Each region manages its own catalog items and rules.

  • Global terms and policies are shared from the Organization group.

  • The EMEA group is isolated to prevent accidental sharing with other regions.

How to set it up

Choosing the right model

What to consider Project-centric Curated Federated

Organization size

Small teams

Mid-size

Large or multinational

Governance maturity

Low: no central function

Medium: central team exists

High: multiple governance layers

Data sharing needs

Minimal: projects are independent

Moderate: shared standards, separate work

Complex: some shared, most separated

Group structure

Flat

Two levels (central + teams)

Multiple levels with isolation

Many organizations evolve from project-centric to curated as they mature.

Design your group structure with future growth in mind, but don’t over-engineer. Start simple and add complexity as needed.

Cross-functional access

Sometimes users need access across organizational boundaries. For example, an auditor who reviews assets from multiple business units without being a member of those units.

To address this, you can:

  • Create a cross-functional group: Add the auditor to a dedicated "Auditors" group, then share relevant assets with that group.

  • Share with individual users: Share specific assets directly with the auditor (use sparingly).

  • Use parent group placement: If appropriate, place the auditor in a parent group that has oversight of the relevant child groups.

Was this page useful?