Requests allow users to suggest changes to assets that they cannot directly change themselves.
Let's break that down a little bit:
- Admin users can directly change assets where they have permission, and suggest changes to all other assets.
- Member users can directly change assets where they have permission, and suggest changes to all other assets.
- Guest users can only suggest changes to an asset if the admin has enabled requests for guests.
Examples
The key point to understand is the statement "where they have permission". As described in How do I control access to metadata and data? there are many options in Atlan to control these permissions.
So let's look at a few examples:
Connection admin permissions
In the simplest case, connection admins:
- Have direct edit access to all assets in a connection
- Both admin users and member users can be connection admins
Connection admins will generally not be able to suggest changes to assets in their connection, because they can make changes to them directly. (The only exception to this is described below — when the edit permission granted to connection admins by default is overridden by a policy that explicitly denies edit permissions.)
Policy-based permissions
You can grant more granular permissions through access policies:
- Control the subset of assets in a connection that can be directly changed (or not)
- Control the specific characteristics of assets that can be directly changed (or not)
For example, in a metadata policy you could specify that:
- For any assets (tables, columns) in a certain schema,
- a certain group of users can only add or remove terms (no other changes).
In this example, any admin users or member users in that group will still be able to suggest other changes to the assets in that schema. (For example, changes to the description, owners, certification, or tags.)
Overridden permissions
Keep in mind, though, that explicit restrictions always take priority. This means even when one policy (or being a connection admin) would otherwise give permission to change assets directly, it is possible to override that permission.
For example, in a metadata policy you could specify that:
- For any assets (tables, columns) in a certain database,
- all updates are explicitly denied to a certain group of users.
Even if a user does have permission to directly update an asset from some other policy, this explicit deny policy will take priority. In this case, the user will only be able to suggest changes to the assets in that database. It does not matter if they are an admin user or member user, or even a connection admin.