Configure Permissions for Curation Automation¶
Alation Cloud Service Applies to Alation Cloud Service instances of Alation
When you run a curation rule, Alation enforces your existing permissions before it updates any field value, the same way it does for manual edits. A rule can only change the objects and fields you have the right to edit. These checks are always on and cannot be disabled by an admin.
These checks use the permissions already set on your custom fields and objects. You do not set them up in Curation Automation. To change what you can curate, update the custom field permissions or the object’s access settings. This topic explains which permission layers Curation Automation honors and what happens when an update is blocked.
Note
Server Admins and Catalog Admins are exempt from rule ownership restrictions and from the Limit to assigned objects stewardship filter (see Configure Access to Curation Automation). They are not exempt from the custom field and object-level permission checks described on this page. Like any user, an admin can only curate fields and objects they have permission to edit.
Understand the Permission Layers¶
Curation Automation applies the same permissions you already have when you edit objects and fields directly. For every object in a rule’s target set, it checks two permission layers before it updates a field:
Custom field permissions: whether the target field is restricted to specific user groups or people sets, and whether you are allowed to edit it.
Object-level access: whether you have edit access to the object.
If either check fails, Curation Automation skips that object or field. For more about how access and permissions work across the catalog, see Access, Roles, and Permissions.
Check Custom Field Permissions¶
A custom field can be restricted so that only specific user groups or people sets can edit it. Curation Automation honors these restrictions: when a rule targets a restricted field, it updates the field only if you are allowed to edit it. For how field permissions are configured, see Manage Custom Fields.
The two kinds of restriction behave differently in the create rule wizard:
Fields editable by a specific user group: If you are not in an allowed group, you cannot add the field. It does not appear in the field picker. If the field is already in the rule, Alation shows a warning that you cannot edit it. That field is skipped when the rule runs.
Fields editable by a people set: A people set lists the users assigned to an individual object, such as the object’s Expert or Steward. You can add this kind of field. The allowed users depend on each object’s assignments, so Alation checks each object when the rule runs. It skips the objects where you are not in the allowed people set. For more about people sets, see About Templates and Fields.
Check Object-Level Access¶
For policies, documents, and glossaries, Curation Automation checks whether you have explicit edit access before it updates the object:
Policies — see Grant Access to Policies.
Documents — you must have edit access to both the document and its parent folder. See Document Hub Permissions.
Glossaries — see Glossary Permissions.
For data source objects (schemas, tables, and columns), whether a data source is private or public affects object-level access. If you do not have access to a data source, you cannot curate its objects, and those objects are skipped.
Objects that are not browsable in the catalog are excluded from curation for all users, including Server Admins and Catalog Admins. Because these objects never enter a rule’s target set, the object counts you see can be lower than you expect.
Understand Skipped Curation Actions¶
When either check fails:
The curation action is skipped.
No field value is updated.
No curation action or Alation Consumption Unit (ACU) is consumed for the skipped field or object.
This enforcement is additive with the Limit to assigned objects setting. If an admin has limited you to assigned objects, both filters apply independently to the same run. See Configure Access to Curation Automation.
Preview the Filtered Scope¶
The scope picker does not apply the Limit to assigned objects filter. When you select specific schemas, tables, or columns, you see all objects. This lets you select a parent schema or table to narrow your scope even if you steward only its child objects.
Your edit permissions and the Limit to assigned objects filter apply when Curation Automation estimates and runs the rule, not while you configure the scope:
The estimated actions count reflects only the objects and fields you can edit. If Limit to assigned objects is enabled for you, it also counts only the objects you steward. The remaining objects and fields are reported as skipped.
If you do not have permission to edit some fields, the Preview and Run step shows a warning. The warning tells you that those fields will be skipped and that no credits are charged for them.
A notice at the top of the wizard explains that results are filtered to your permissions. When Limit to assigned objects is enabled for you, the notice explains that results are limited to objects you are assigned to steward and that objects you do not steward or cannot access are skipped.
Review Permission Skips in the Rule Run Report¶
After a rule runs, the run report lists every object that the rule skipped. When the rule skips an object for a permission reason, the report notes that the user who ran the rule lacked permission to edit it. Skipped objects do not consume a curation action, so the report separates them from the objects that were curated. For how to open and download the report, see Review the Execution Report.