User Community Service Desk Downloads
If you can't find the product or version you're looking for, visit support.ataccama.com/downloads

Share Access to Assets

Sharing access is the means of providing access to other groups and users on the asset level. If a data asset is not shared and no stewardship group is selected, it is only visible to the user who created it. By default, this user gets the Full access level to this asset.

If default settings are used, only administrators or users with the appropriate sharing permissions can manage the access rights for a data asset. For example, a user who is a member of Group A and has full access level rights can share this group’s catalog items with the whole Group B or particular users from Group B. This can be configured through the manageAccess operation settings for each entity for each access level. For more information, see Access Levels.

You can monitor the manageAccess operation in the Audit module. This includes information about the users, groups, and access levels involved in the operation. For more information, see Audit.

How sharing works

Before sharing access to assets with other groups and users, get familiar with how sharing functions. It mainly depends on the group hierarchy, user roles, and inheritance.

Therefore, consider how your assets should be shared when creating the group structure. For more information, see Groups.

How sharing works for groups and users

When sharing access with a group or a specific user, keep in mind that:

  • A user receives access to all data assets that are shared with the group of which this user is a member.

  • When sharing a data asset with a group, all members always receive the lowest access level possible as determined by the following:

    • Their governance role within the group.

    • The access level that was selected when the data asset was shared.

      If a user has a governance role in a group with a View Data access on a rule, and someone shares this rule with the user’s group with an Edit access level, this user still has only a View Data access to this rule.

      Similarly, if a user has a role with a Full access in a group, and someone shares a rule with the user’s group with an Edit access level, this user gets only Edit access rights on this rule.

  • If you share a data asset with a specific user only (and the asset is not shared with the group this user is a member of), the user gets the access level selected when the asset was shared with them. The user’s governance role in any group has no impact on sharing in this case.

  • If you share a data asset with a specific user and with a group this user is a member of, the user receives the highest access level available between the one that is allowed by the user’s governance role within this group and the access level selected when the asset was shared with the user directly.

    If a user has a governance role in a group with a View Data access on the term entity, and someone shares a term with both (the user’s group with an Edit access level and with the user specifically with Full access level), the user gets a Full access to this term.

    Similarly, if someone shares a term with the user with only a View metadata access level, the user still gets View Data access rights on this term.

  • All users in a parent group automatically receive access to all data assets that are shared with at least one child group with the same access level settings. The same applies to any previous ancestors on the group hierarchy tree. This concept is called oversight.

    For example, we have three groups in a hierarchy as follows: Group A > Group B > Group C. If a catalog item is shared with an Edit access level with Group C, both Group B and Group A receive an Edit access level on the shared catalog item. The group Organization also gets an Edit access to this catalog item as the top parent group.

    Oversight concept diagram

    Additionally, the oversight is single-direction only: all ancestors receive access, but the descendants of those ancestors do not.

    Let’s take a look at the following hierarchy: Group A > Group B and Group A > Group C. If a catalog item is shared with an Edit access level with Group C, Group A receives an Edit access level on the shared catalog item, but Group B does not receive access to this catalog item.

    Inherited access example

    If you want to share access only with the top-level group, such as Organization and nobody else, you can create a separate group under Organization with the same users and share access with this newly created group. That way, only these particular people get access to the entity you’re sharing.

  • All users in the child groups receive access to all data assets that are shared with a parent group.

    For example, we have four groups in a hierarchy as follows: Group A > Group B > Group C and Group A > Group D. If a catalog item is shared with an Edit access level with Group A, all child groups (Group B, Group C, and Group D), receive an Edit access level on the shared catalog item.

    The group Organization also gets an Edit access to this catalog item because of the oversight, as explained in the previous section. If you know that certain assets (for example, terms) need to be shared with everyone, you can share them with the Organization (top parent group).

    Inherited access example two
  • Sharing can further be controlled by setting up isolated groups and branches (groups and their children). When a group is isolated, members of the group or branch are restricted from sharing assets and assigning stewardship to assets outside of their group or branch. For more information, see Groups, Group isolation section.

    In the following example, we have set the Europe group to be isolated, which is passed down to the child groups Sales EMEA and Marketing EMEA. The previously explained concepts related to sharing still apply, the only difference is that members of the Europe branch can only share and assign stewardship within the isolated branch.

    This means that members of Sales EMEA can share assets with members of Europe, Sales EMEA, and Marketing EMEA but not APAC or the North America branch. Members of the isolated branch can also only assign stewardship of assets to groups within the branch.

    Note that the Organization group keeps access to all assets through the oversight mechanism, which remains unaffected. This also means that sharing with individual users who are members of parent groups of the isolated branch is still allowed. However, this does not apply to stewardship assignment or sharing with the entire group because it would result in passing access to groups outside of the hierarchy of the isolated group.

    The same would apply to the isolated group of Marketing NA and any potential child groups: * Members of Marketing NA can only share access to members of Marketing NA and, due to the oversight mechanism, to individual members of North America and Organization. * North America and Organization groups keep access to Marketing NA assets. * Members of Marketing NA can only assign stewardship to their own group.

    Members of groups that are outside of isolated branches are not restricted from sharing assets and assigning stewardship to the isolated group or any other.

    Take note of the following:

    • If a user is a member of two isolated branches, the user can share any asset within both unless stewardship is already assigned to one of the branches.

    • If assets were shared with users outside of a branch before the branch became isolated, these settings remain unaffected. Revoke access manually as needed.

    Isolated groups example

With preceding mechanisms in mind, we recommend that you avoid adding users to the top Organization parent group because these users would automatically get access to all entities shared with any child groups.

To prevent this, the best practice is to manage individual users in groups under the Organization parent group. You can use the Organization parent group if you need to share assets with the entire organization regardless of whether it contains any users as the access rights will be inherited.

For more information about groups, see Groups.

Sharing entities with inheritance

When sharing access with users or groups to data assets of entities with hierarchy (for example, the source entity has the catalog item entity as a child node on the metadata model graph), keep in mind that:

  • If you share access with users or groups for a parent entity type asset, these users or groups automatically get the same access level on all assets that are child entities of the parent entity.

    For example, if you share access with a group to a Source A with an Edit access level, this group receives an Edit access level on all child instances of the source entity, such as all catalog items of Source A.

    You can check all the descendants of any entity in the metadata model (check the node on the metadata model graph).

  • You can increase the access level to a specific child entity asset for a group or user. This requires creating an additional sharing record for this specific data asset.

    Additional sharing record

    When assets of both parent and child entities are shared with a group or a user, the highest access level between the shared ones is applied.

    For example, if you share a source with Group A with a View metadata access and then share a specific catalog item of this source with Group A with Full access, the group receives this catalog item with Full access.

    However, if you share a source with Group A with a Full access and then share a specific catalog item of this source with Group A with Edit access, the group still receives this catalog item with Full access.

Sharing notifications

When sharing an asset, notifications work as follows:

  • When you share a data asset with a user or make adjustments in the shared access levels, this user gets a notification about the changes.

  • When you share a data asset with a group or make adjustments in the shared access levels, all users in this group get a notification about the changes.

  • When you remove access for a user or a group, users do not get any notifications.

Manage access

See the following steps to share or remove access from a group or a user.

Share access

When you’re sharing access, you can see the default access level as defined on the Access Levels tab of the entity (for example, View Metadata Access) next to the group or user name.

If the access level you want to assign is not available for the asset, you need to add this level to the entity configuration. For more information, see Access Levels, section Configure access levels on entities.

If the editing option is not available, it means the access is inherited from the parent entity. In that case, you can edit the access level only from the parent asset.

To share access or change the access level to a data asset for a group or a user:

  1. Go to the Overview tab of an asset.

  2. Select Share.

    share icon example
  3. Search for users or groups with whom you want to share access and add all that apply.

  4. Expand the list of access levels next to the group or user name and select the required access level.

    share access dialog
  5. Select Done to save changes.

Remove access

To revoke access from a user or group:

  1. Go to the Overview tab of an asset.

  2. Select Share.

  3. For all the required users or groups, expand the list of access levels next to their name and select Remove Access.

  4. Select Done to save changes.

Was this page useful?