How Access Is Evaluated
This page explains how sharing, stewardship, governance roles, and group and asset hierarchies combine to determine what you can do with an asset. Use it when you set up groups and governance roles, or when access to an asset isn’t what you expect.
To check a real case, use the Explain permissions report in the three-dot menu of the asset. See Explain permissions.
Access levels and operations
An operation is a single action on an asset, such as viewing, editing, or publishing it, and plugins can add their own operations. An access level is a named set of operations, for example, Editing access. Sharing, stewardship, and governance roles all work with access levels, but what you can do is always determined per operation.
The operations in an access level are defined per entity in the metadata model, so Editing access on a term is not the same set of operations as Editing access on a source. Each entity also defines the access level that the creator of a new asset gets (Assign when asset is created), usually Full access.
See Access Levels.
Where access comes from
You can get access to an asset in the following ways:
-
The asset is shared with you or with a group you’re a member of, at a specific access level. See Manage and Explain Access to Assets.
-
A group you’re a member of owns the asset through stewardship. Stewardship works as a share at the creation level of the entity, usually Full access, and additionally defines the owner of the asset. See Stewardship.
-
You created the asset and got the creation level of the entity.
-
You have access to a parent asset. For example, access to a source applies to all locations, connections, and catalog items under it.
Everything that reaches you adds up, and the highest access level wins. A lower share on a child asset cannot reduce what you get from the parent asset.
How governance roles limit access
Governance roles do not grant access. A governance role sets the maximum access level that members of a group can get on each entity through that group. A share made directly with you isn’t limited by a governance role and gives the access level it was shared at. See How governance roles limit access.
Asset hierarchy
Sharing and stewardship are hierarchical. A share or stewardship on a source applies to everything under it: its locations, connections, and catalog items. See Sharing entities with inheritance.
Group hierarchy
A share with a group reaches the members of its child groups. Members of all its parent groups receive the same access level as well, which is called oversight. For an example of how oversight works, see How sharing works for groups and users.
A share never reaches sibling groups. See Group hierarchies.
Group membership
You become a member of a group when a governance role is assigned to you, or to one of your identity provider roles, in that group.
You can hold different governance roles in different groups.
By default, all users with the MMM_user identity provider role are members of the Default group with the Data Consumer governance role.
See Groups.
Exceptions to sharing-based access
-
Users with the
MMM_adminidentity provider role bypass all permission checks. By default, this role is attached to the ONE Administrator governance role. -
Top-level assets, such as sources, terms, rules, and monitoring projects, have no parent asset to inherit access from. For these, the governance role alone determines whether you can create a new asset. For example, a role with Full access on the
sourceentity lets you create sources. -
Settings entities, such as System, User Management, and DQ Configuration, are shared with the top-level
Organizationgroup at Full access by default. Because every group sits underOrganizationin the hierarchy, the governance role alone determines what you can do with them. -
Some entities are public, and everyone can perform every operation on them. This applies to jobs, notifications, and the relationships between catalog items, terms, and rules.
Was this page useful?