Sharing Access to Assets
Sharing grants access to users and groups beyond the asset’s owner. It’s how you make assets visible to people who need them but aren’t part of the stewardship group.
What sharing is for
Stewardship establishes who owns an asset. Sharing extends access to other users.
Some common scenarios include:
-
Organization-wide visibility: Share approved business terms with your root group so everyone uses consistent definitions.
-
Cross-team collaboration: Give the analytics team access to catalog items owned by data engineering.
-
Limited access for reviewers: Let compliance view sensitive assets without editing rights.
-
Temporary project access: Grant a project team access to specific assets for the duration of their work.
How sharing works
When you share an asset, you select:
-
The groups or users to share with.
-
An access level (such as view metadata, view data, editing, full access).
The recipients can now access the asset, though their effective access level might differ from what you selected depending on how you shared.
Sharing with groups vs. sharing with users
How access is determined depends on whether you share with a group or directly with a user.
-
When you share with a group: The recipient’s effective access is the lower of the shared access level and what their governance role allows.
For example, if you share at "Full access" with a group, a Data Consumer in that group still only gets view access.
-
When you share directly with a user: The recipient gets the access level you selected, regardless of their governance role in any group.
For example, if you share at "Full access" directly with a user who is a Data Consumer in Group A, they get full access to that asset. Their role in Group A doesn’t limit them.
This makes direct user sharing useful for exceptions but also means it bypasses the guardrails that governance roles provide.
Multiple sharing paths
If a user has access to an asset through multiple paths (such as different groups, direct sharing, stewardship), they get the highest access level available. For example:
-
A user has view access through Group A.
-
The same user has edit access through Group B.
-
They can edit the asset.
How group hierarchy affects sharing
Your group hierarchy determines how shared access flows. For background on inheritance and oversight, see Why hierarchy matters.
When sharing, keep these practical implications in mind:
-
Sharing with a parent group shares with all descendants. If you share an asset with "Analytics," every child group (Finance Analytics, Marketing Analytics, etc.) also receives access.
This is efficient for broad visibility but means you can’t easily exclude a specific child group.
-
Parent group members see what’s shared with child groups. Before sharing sensitive assets with a team, consider who sits above them in the hierarchy.
A manager in the parent group will automatically have visibility, which might be appropriate for oversight, or might be a concern depending on the data.
-
Share at the right level. For organization-wide assets (like approved business terms), share with the root group. For team-specific assets, share with the specific group to avoid unintended access.
Asset inheritance
Just as stewardship flows down through asset hierarchies (see Stewardship inheritance), so does shared access.
When you share a parent asset, child assets inherit that access. For example, sharing a source with a group also grants access to all catalog items within that source.
You can override inherited access on child assets by sharing them separately at a different access level.
Best practices for sharing
-
Prefer groups over individual users. Sharing with groups keeps access consistent as team membership changes and makes auditing easier. If you find yourself sharing with the same individuals repeatedly, consider creating a group for them.
-
Use direct user sharing sparingly. Reserve it for cases where creating a group isn’t practical, like one-time access requests or external collaborators. Too many individual shares become difficult to track and audit.
For examples of sharing approaches based on your organization type, see Access Management Models.
Isolated groups and sharing
When a group is isolated, its members can only share assets within their own group or branch. This prevents accidental sharing outside a team’s scope.
However:
-
Users in parent groups can still share assets with the isolated group.
-
If access was shared before the group became isolated, it remains until manually revoked.
For more on isolation, see Groups.
Was this page useful?