Anomaly Permissions¶
Understanding who can act on anomalies
What you can do with an anomaly depends on two layers: the team permission you have on the datastore the anomaly belongs to, and, for a few actions, your platform-wide user role. This page gathers every anomaly action in one place.
For the user roles and how they compare, see User Roles. For every team-permission-gated action across the platform, see Team Permissions.
Admin bypass
Users with the Admin role bypass every team-permission check on every datastore.
Permission Matrix¶
The table shows which team permissions on the anomaly's datastore can perform each action:
Actions Outside the Matrix¶
Some actions do not follow a team permission:
| Action | Who can do it |
|---|---|
| Edit a comment | Only its author. An Admin cannot edit someone else's comment. |
| Delete a comment | Its author, or any user with the Admin role. |
| Read the Masking Audit Log | Users with the Admin role. |
| Be mentioned in a comment | Any active user, even without access to the datastore. They are notified but cannot open the anomaly. |
Key Details¶
- Archived anomalies are read only. Whatever your permission, an archived anomaly's status, tags, assignees, description, tickets, and comments cannot change until it is restored. Restoring needs the Author team permission.
- Assignees need access. The assignee picker lists only users with at least the Viewer team permission on the datastore, so an anomaly cannot be assigned to someone who cannot see it.
- Visibility follows the teams. A user with no team on the anomaly's datastore does not see its anomalies at all, in any list.
- Controls follow your permission. Buttons for actions you cannot perform are hidden or disabled. A ticket's sync mode button stays visible without the permission, so everyone can see which mode it is in, but it cannot be clicked.
- Flows act on their own. A Flow that archives anomalies or creates tickets does not need the permissions of the person who receives its notifications. Managing the Flow itself has its own requirements. See Flow Permissions.
See Also¶
-
How It Works
How a Scan creates anomalies, AI Managed and Authored checks, the lifecycle, duplicates, and notifications.
-
Record Anomalies
Anomalies that flag one row: when they are created, how rows are grouped, and examples.
-
Shape Anomalies
Anomalies about many rows or the whole dataset: what creates them, what they count, and examples.
-
AI Managed and Authored
How anomalies from AI Managed and Authored checks differ, the AI badge, and how triage tunes AI Managed checks.
-
Impact
How the Low to Critical impact level is decided from the failed checks, and when it updates.
-
Status
The lifecycle of an anomaly, from Active and Acknowledged to the archived statuses.
-
Assignees
How the Assignees field works, who can be assigned, and when assignees are notified.
-
Fingerprints
How Qualytics recognizes a newly detected anomaly as a duplicate of one it already found.
-
Anomaly Views
The four screens that show anomalies: how to reach each one, what it shows, and what you can do there.
-
Description
The business-friendly explanation of the data quality issue behind an anomaly.
-
Source Records
The rows behind an anomaly, how to read them, and how masked values are protected.
-
Tickets
Linked Jira and ServiceNow tickets: sync modes, what reaches the ticket, and status sync.
-
Timeline
The record of every change to an anomaly, and how comments and mentions work.
-
Examples
Real scenarios that follow an anomaly from the Scan that finds it to the decision that closes it.
-
Best Practices
Guidelines for keeping the anomaly list short, trusted, and acted on.