Skip to content

Anomalies FAQ

Answers to common questions about anomalies in Qualytics. Sections are grouped by topic; pick the heading closest to what you are working on.

General

What is an anomaly?

An anomaly is a data point that deviates from the expectations a quality check defines. A check that requires customer_id to be non-null produces an anomaly for every row where that field is null in a given scan. Anomalies are how Qualytics surfaces what needs human attention.

How are anomalies created?

Anomalies are created automatically by Scan operations. When a scan runs, every Active quality check is evaluated against the scoped data, and rows or schema observations that fail the check produce anomalies. See How Anomalies Work for the full pipeline.

What's the AI badge on an anomaly?

The AI badge (purple pill with a four-point star) marks an anomaly whose failed checks are all AI Managed. Hovering reveals "Identified by AI managed checks." See The AI Badge for the criteria.

Types

What is the difference between Record and Shape anomalies?

A Record anomaly flags a single row that fails a value-level check (missing value, out-of-range, pattern mismatch). A Shape anomaly describes a problem across many rows or the dataset as a whole: a structure change such as a missing column, a dataset-level check such as Unique, a row-level check whose coverage is set below 100%, or the rollup created when a check fails more rows than the Maximum Record Anomalies per Check limit. See Record Anomalies and Shape Anomalies for examples of each.

Can a single anomaly mix both types?

No. Each anomaly is either record or shape. The two share the same status, history, and notification surface, but their failed_checks semantics differ: record anomalies link to the row-level checks each row failed, while shape anomalies link to the structural, dataset-level, coverage, or rolled-up check that produced them.

Why does one row produce several anomalies?

The row's container has One anomaly per check turned on. With that setting, a row that fails several checks produces one record anomaly per failed check, each with its own status, assignees, and notifications. With the setting off (the default), the row produces one anomaly that lists every check it failed.

Can one shape anomaly cover several checks?

No. Every shape anomaly has exactly one failed check. When several checks fail at the shape level, even on the same fields, each one produces its own shape anomaly.

Impact

How is an anomaly's Impact decided?

Each check that failed in the anomaly is rated by how much failed: the share of checked records that failed, whether the check tests the table as a whole, and whether one of the check's impact metrics is outside its expected range. That rating is raised or lowered by the check's Importance, and the anomaly takes the highest level among its failed checks. Hover over the impact on the anomaly to see what decided it. See Deep Dive · Impact for the full rules.

Why did an anomaly's Impact change?

The Importance of one of its failed checks changed while the anomaly was open: a tag was added to or removed from the check, a tag's weight was changed or the tag was deleted, or an AI Managed check was converted to Authored. The anomaly's timeline records the change and who caused it.

Does tagging an anomaly change its Impact?

No. Tags on the anomaly itself do not affect its impact. Only the tags on the checks that failed do, through each check's Importance.

Why didn't the Impact of a resolved anomaly change?

An anomaly that is no longer open (Resolved, Duplicate, Invalid, or Discarded) keeps the impact it had when it closed. Only Active and Acknowledged anomalies are updated.

Can I filter anomalies by Impact?

Yes. The Impact filter of the anomaly lists shows only the anomalies at the levels you pick, or hides them with is not any of. In the API, pass impact_level to GET /api/anomalies. The lists also sort by Impact, which is their default order. To act on anomalies at, above, or below a level as they happen, set Anomaly Impact on a Flow trigger. See Filter and Sort Anomalies, Anomalies API, and Configure a Trigger.

Is Impact the same as a check's Importance?

No. Importance belongs to a check and says how much its failures matter. Impact belongs to an anomaly and combines how much failed with the Importance of the checks that failed. See Check Importance.

Status and lifecycle

What is the difference between Active, Acknowledged, and Archived?

Active means the anomaly was detected and nobody has triaged it. Acknowledged means someone reviewed it and decided it needs follow-up but is not yet resolved; it remains in the open queue. Archived is a terminal state with one of four resolutions: Resolved, Duplicate, Invalid, or Discarded. See Deep Dive · Status for what each resolution means.

Can an Acknowledged anomaly go back to Active?

Yes. While an anomaly stays in the open queue you can switch freely between Active and Acknowledged with Acknowledge and Reactivate. Acknowledgement is a soft label, not a one-way gate. The only direction that is blocked is Archived → Active: to bring an archived anomaly back, restore it (which lands it in Acknowledged, not Active).

How do I restore an archived anomaly?

Open the anomaly and click Restore, or call PUT /api/anomalies/{id} with "status": "Acknowledged". The anomaly returns to the Acknowledged state. It cannot go directly back to Active. See Restore Anomalies.

Fingerprints and duplicates

What is an anomaly fingerprint?

A fingerprint is a deterministic identifier the platform generates for each anomaly. Two anomalies that describe the same issue on the same data get the same fingerprint, so Qualytics can detect and archive duplicates automatically. See Deep Dive · Fingerprints.

Why are my truncate-and-reload tables generating duplicate anomalies every scan?

Because every reload creates fresh _qualytics_self_id values, which makes the record look new to the engine. Enable both Archive Duplicate Anomalies and the fingerprint-based handling described in Fingerprints · Truncate-and-reload tables so the platform recognises the recurring rows.

Should I archive an anomaly as Duplicate or as Discarded?

If you can identify the original anomaly the new one duplicates, set Duplicate and reference the original in the comment. If you can't (or the engine archived it on its own without a back-reference), prefer Discarded to keep fingerprinting accurate.

Tags

Can I tag many anomalies at once?

Yes. Use Bulk Edit Anomalies from any anomaly list except Explore › Anomalies, which has no bulk actions. Turn on the Tags toggle, pick the tags, and save. See Bulk-Edit Tags for the full flow. Choose Overwrite to replace the tags on each selected anomaly, or Add to keep their current tags and add yours.

Do anomalies and checks use the same tags?

Yes. Anomalies and checks pick from the same tags (see Tags), so a tag like HIPAA means the same thing wherever it appears. A team tag can be applied only by members of its team and by users with the Admin role.

Comments and tickets

Who can comment on an anomaly?

Anyone with at least the Viewer team permission on the datastore can post comments and replies. Reading the Timeline and its comments requires the Reporter team permission. Editing a comment is restricted to its author, and deleting one is restricted to its author or a user with the Admin role. See Timeline.

Can I comment on a specific change instead of the anomaly itself?

Yes. Click the Comment control below a Timeline entry and the comment stays attached to that change, so a status change or a description edit carries the reason for it. See Commenting on a Specific Change.

Can I reply to a comment?

Yes. Click Reply below a comment. Threads are one level deep, so you reply to a comment, not to a reply. Deleting a comment that already has replies leaves a placeholder so the replies stay visible.

Can I mention a teammate in a comment?

Yes, use the @ token and pick from the autocomplete. Mentioned users receive an in-app Mention notification that opens the anomaly, expands the thread, and highlights the comment. See Mention Notification for the full behavior, including who is notified when a comment is edited.

Can I stop Qualytics writing to one linked ticket?

Yes. Each ticket card carries a Two-way / Read only button that applies to that ticket alone, so the anomaly keeps syncing with the others. Read only stops comments, status notes, and status transitions for it, while its status, title, and comments are still read back. Nothing is resent when you switch it back. Changing the mode needs the Manager role plus the Author team permission on the datastore, and an Admin can change it regardless of team membership. See Change a Ticket's Sync Mode.

Why is the Two-way button missing from a ticket card?

Because the integration itself is set to read only, and no ticket can be written to while that is the case. The button comes back when an administrator switches the integration to two-way sync. Without the Author team permission the button is shown but cannot be clicked, so the mode is visible to everyone. Saving a change also needs the Manager role.

Yes, once the corresponding Ticketing Integration is configured. From the anomaly details, click Link or create ticket in the Tickets section to link an existing ticket or to open a new one. Linking requires the Manager role plus the Author team permission on the datastore.

Does linking an existing Jira issue modify it?

No. Linking only records the association in Qualytics. The issue is written to later, when you acknowledge, archive, or comment on the anomaly, and only while that issue is synced two-way.

Both. Each link is tracked on its own. When Anomaly status sync is on, remember that every issue linked to an anomaly has a say in whether the anomaly moves.

Why did the anomaly's status change on its own?

Because a linked ticket reached a status that the integration's mapping pairs with an anomaly status, and Anomaly status sync is on. The anomaly moves only when every ticket linked to it sits at a status mapped to the same anomaly status, read only tickets included. The change is recorded on the Timeline like any other, and Flows on Anomaly Status Changed run for it. See Anomaly status sync.

A linked ticket was closed and the anomaly did not move. Why?

One of three reasons. Another ticket on the same anomaly is still at a status that maps elsewhere, and all of them have to agree. The ticket's new status is not named in the mapping, and a status the mapping does not know never moves anything. Or the anomaly is already archived, and a ticket never reopens an archived anomaly.

A comment written on the ticket is not at the top of my Timeline. Where is it?

At the time it was written on the ticket, not the time Qualytics read it. A comment that took a while to arrive lands at its own point in the conversation, which keeps the thread readable but means the newest entry is not always the last one added.

My comment never reached the linked ticket. Why?

Because nothing is written to a ticket that is read only, either because the integration itself is set that way or because that one ticket is. Comments written while it was read only are not sent when it goes back to two-way. See Change a Ticket's Sync Mode.

What happens to linked tickets when I archive or delete an anomaly?

Archiving keeps the links, and the archive itself is posted to every two-way ticket as a status note. Deleting the anomaly removes its links along with it. In both cases the tickets stay in Jira or ServiceNow, with everything Qualytics already posted on them.

Source records

Why doesn't my anomaly have source records?

Source records require a linked Enrichment Destination on the source datastore. Without one, the platform has nowhere to store the failing rows, and the Source Records section on the anomaly stays empty. See Source Record.

How fresh are the source records I see?

Source records are cached locally for up to 8 hours to keep the UI responsive. Click the Refresh button in the Source Records toolbar to bypass the cache and re-fetch from the API.

How many source records can I download?

The CSV download includes every record that was captured during the scan, up to the maximum source records per anomaly configured in your Scan settings. The CSV is capped at 250 MB.

Can I see the raw value of a masked field?

Only if you have the Editor team permission on the anomaly's datastore. The download/view request must include include_masked=true, and the platform records an audit-log entry naming each masked field you read. See the Source records API.

Why does the RECORD column stay masked in the Source Records container after I click Show masked values?

The Source Records container of an enrichment datastore keeps the source rows of anomalies from many containers in a single RECORD column, and each row is kept as history from the moment the anomaly was detected. A field can be masked on its container after that, and masking cannot reach individual fields inside the JSON, so Qualytics masks the whole column every time it is read. Show masked values does not apply to it, and changing the RECORD field to Active does not either: it goes back to Masked the next time the enrichment datastore is synced or profiled. This is intended. To see the values, open the anomaly and use its Source Records tab, where users with the Editor team permission can reveal masked fields. See Why the RECORD Column Is Always Masked.

Why do I get ***MASKED*** when I query the enrichment source-records table through the API?

GET /api/datastores/{id}/source-records?path=..._source_records reads the enrichment output directly, and on that route the platform replaces the whole RECORD column with ***MASKED*** for every row, whatever the masking status of the underlying fields. There is no parameter to unmask it. The anomaly endpoints are the supported path for the values: call GET /api/anomalies/{id}/source-record (JSON) or GET /api/anomalies/{id}/source-record/download (CSV) with include_masked=true. That requires the Editor team permission on the anomaly's datastore and writes an audit-log entry. The other enrichment outputs (_failed_checks, _check_metrics, _scan_operations) are returned unmasked by the datastore route.

Assignees

Why didn't a new anomaly auto-assign anyone?

Auto-assignment only happens when at least one of the quality checks that produced the anomaly has a Default Anomaly Assignee set. If every contributing check has the default empty, the anomaly is created with no assignees. See Inheritance from the originating check.

I changed the check's Default Anomaly Assignee. Why didn't existing anomalies pick it up?

Inheritance happens only at the moment the anomaly is created. Updating a check's default later does not retroactively change anomalies that already exist. To update them, edit the anomalies directly (individually via Add Anomaly Assignees or via Bulk-Assign Anomalies).

Two checks failed on the same row. Whose default assignee wins?

Both, by default. When an anomaly is produced by multiple failed checks, the default assignees of every contributing check are combined into a single list with duplicates removed, then applied to the anomaly. So a row that fails check A (defaulting to Alice) and check B (defaulting to Bob) creates an anomaly with Alice and Bob as assignees. When the container has One anomaly per check turned on, the row instead produces two anomalies: one for check A assigned to Alice, and one for check B assigned to Bob.

Can a user with only the Viewer team permission be an assignee?

Yes. Viewer is the minimum requirement to be assigned. Viewers see the anomaly and receive notifications, but they cannot edit the assignee list themselves.

A user does not show up in the assignee picker. Why?

The picker only lists users that have at least the Viewer team permission on the datastore where the anomaly lives. If a teammate is missing, check their team membership in Team Permissions.

Do I get notified when I assign myself to an anomaly?

No. You do not receive notifications for changes you make yourself. Other assignees on the same anomaly do get notified.

What about the very first time an assignee is added? Do they get a notification?

Yes. A newly added user is part of the recipient set for the same update event, so the first thing they hear about the anomaly is the Assignment notification linking to it.

Can I edit assignees on an archived anomaly?

No. Archived anomalies are read-only with respect to assignees. Restore the anomaly to Acknowledged first. See Restore Anomalies.

How do I unassign everyone from an anomaly?

Open the anomaly, click the Edit button next to Assignees, and remove every selected user. Via the API, send "assignee_ids": []; see API · Manage assignees.

Can I filter for anomalies that have no assignees?

Yes. In the Assignee filter, switch the drop-down next to its name to is empty. The list shows only the anomalies no one is assigned to. Through the GET /anomalies endpoint, send filters={"assignee":{"empty":true}}.

What is the difference between the Assignees filter and the Assigned subtab?

The Assignees filter lets you pick any users and shows anomalies assigned to any of them. The Assigned subtab (inside the Open tab) is a one-click shortcut to "open anomalies assigned to me," scoped to your own user.

Permissions

Who can view an anomaly?

Any user with at least the Reporter team permission on the datastore that produced the anomaly. Downloading the anomaly's source records needs the Viewer team permission, and seeing unmasked values in them needs Editor.

Who can edit an anomaly?

Users with the Author team permission (or higher) on the datastore can edit status, tags, assignees, and the description. Archive and delete also require the Author team permission. Linking external tickets requires the Manager role plus the Author team permission on the datastore.

Can a Member without team access see an anomaly?

No. Anomaly visibility is scoped to the team permissions on the datastore. A Member without any team that owns the datastore sees an empty list.

Can I combine filters?

Yes. Every filter narrows the same result set, and the filters are combined with AND. Within a single filter (for example, Tags), values are combined with OR by default. So Tags: HIPAA, SOX + Status: Active returns active anomalies tagged with HIPAA or SOX. To change that, switch the drop-down next to the filter's name: is all of keeps only the anomalies tagged with both, and is not any of hides the anomalies tagged with either. See Filter & Sort for the full list of supported filters.

Can I search the anomaly message text?

Yes. The Search field (or ?search= on the list endpoint) matches an anomaly's exact ID or UUID, or any part of the message of one of its failed checks, ignoring case.

Bulk operations

What can I bulk-edit on multiple anomalies?

From the UI's Bulk Edit Anomalies dialog: Tags and Assignees. The status has its own bulk actions on the selection bar (Acknowledge, Reactivate, Archive, and Delete on archived anomalies), and the description can only be edited one anomaly at a time. Bulk actions are not available on Explore › Anomalies. The PATCH /anomalies API accepts the status (Active or Acknowledged), tags, description, and assignees per entry if you prefer to script bulk changes. See Bulk-Edit Tags and Bulk-Assign Anomalies for the UI flows. To add assignees to a single anomaly, see Add Anomaly Assignees.

Does bulk edit merge or replace?

For tags, you choose. Next to the Tags label, Overwrite (the default) replaces each anomaly's tags with your selection, and Add keeps each anomaly's current tags and adds your selection. Assignees always replace: previous assignees not in your selection are removed. See Bulk-Edit Tags.

Can I bulk archive?

Yes, from any anomaly list except Explore › Anomalies. Select multiple anomalies, click the Bulk menu button in the selection toolbar, and choose Archive. The API equivalent is the bulk delete endpoint with archive=true. See Bulk archive or delete.