Anomaly Description
The Description is a business-friendly explanation of the data quality issue captured by an anomaly. It appears in the Description section of the anomaly details view, alongside the structured attributes (Status, Severity, Failed Checks, and so on).
For the step-by-step tutorial on editing, see Edit Anomaly Description.
How the default description is built
When Qualytics creates an anomaly, it writes a default description from what the scan found.
The opening line says what failed and where. A Record Anomaly covers the one row that failed:
A Shape Anomaly counts against every row the scan processed, and adds the share that failed:
On a filtered check, that total can be larger than the number of rows the check itself evaluated, which the check's own block reports.
An anomaly that carries no record count, such as one raised by Volumetric or Freshness, names the container instead, labeled the way the platform labels it elsewhere: a table as table (or its table type, such as view), a file container as file pattern, and a computed container as computed table or computed file:
Under a What went wrong heading, one block per failed check follows. Each block names the check at the end, so you can open it from the Failed Checks section, and a check with a filter adds a line naming the rows it looked at. When the blocks would not fit in the 8,000 character limit, the last ones are replaced by a closing line such as …and 3 more checks failed.
Inside each block, the values that matter are set apart: field names appear as inline code, counts and check numbers in bold, and a pattern or SQL expression the check uses on a line of its own, so it can be read and copied in full. The composed description is Markdown and renders on the anomaly page with that formatting.
When a check uses Custom Anomaly Description, its block carries the record's own text instead of the rule's wording.
The default is a starting point: you can leave it as it is, refine it, or rewrite it entirely.
Note
The default description is only set at anomaly creation. Once a user edits the text, re-running a Scan does not overwrite it.
Editing the description
Any user with the Author team permission (or higher) on the anomaly's datastore can edit the description. A pencil icon appears next to the Description label in the anomaly details view; hovering it shows the tooltip Edit description. Clicking the icon opens the description in a rich-text Markdown editor: you see the formatting as you type, selecting text brings up a toolbar (bold, italic, strikethrough, inline code, links, block styles), and typing / opens a menu for inserting blocks such as headings, quotes, lists, code blocks, and tables. Images cannot be added. The editor offers the following actions:
| Action | What it does |
|---|---|
| Edit description | Opens the description in the Markdown editor. |
| Save | Saves the new text and closes the editor. The change is recorded in the anomaly's Timeline. The Save button is disabled while the field is empty or contains only whitespace. |
| Cancel | Discards unsaved changes and reverts to the previous description. |
The pencil icon is hidden on archived anomalies (Resolved, Duplicate, Invalid, Discarded) and for users without the Author team permission.
AI-suggested description
When AgentQ is configured on the deployment, a second icon appears next to the Description label: a sparkle whose tooltip reads Suggest a description. Clicking it asks AgentQ to generate a candidate description from the anomaly's failed checks. The suggestion appears in a card with the following actions:
| Action | What it does |
|---|---|
| Use this / Replace draft | Applies the suggestion. The button is labeled Use this when the description is empty, and Replace draft when it already has content. When there is existing text, the suggested change is first marked over your text in the editor so you can review exactly what would change before applying. An applied suggestion can be undone with Cmd+ZCtrl+Z. |
| Regenerate | Asks AgentQ for a fresh suggestion. Useful if the first proposal does not match the issue. While the request is in flight, the card shows a loading state and the button spins. If the request fails, an inline error appears in the card and Regenerate stays enabled so you can retry. |
| Dismiss | Closes the suggestion and keeps the current description unchanged. |
While a suggestion is under review, the editor is read-only and Save is disabled until you apply or dismiss the suggestion.
If AgentQ is not configured for the deployment, the Suggest button is hidden. For details on configuring AgentQ, see the AgentQ documentation.
For the full suggestion workflow (what the AI reads to build the suggestion, provider timeouts, error handling, and cases where a suggestion is refused), see Description Suggestions in the AgentQ overview. The general workflow described there applies on the anomaly description surface, with the anomaly-specific permission note called out in the AgentQ overview itself.
Note
Your own text has no length limit. The generated default and AgentQ suggestions are capped at 8,000 characters.
Where the description goes
The description travels with the anomaly to notifications and tickets, in the form each destination can show:
| Destination | How the description arrives |
|---|---|
| Anomaly page, In App notifications, and Email | Formatted, with headings, bold, lists, and code as written. An email also carries a plain-text copy for clients that do not render HTML. |
| Jira issues, created by hand or by a Flow | Formatted. The Markdown becomes Jira's own formatting. |
| Slack, Microsoft Teams, PagerDuty, Webhook, and HTTP Action | As plain text. The formatting marks are removed and the words, values, and patterns are kept. |
| ServiceNow incidents, created by hand or by a Flow | As plain text, the same way. |
| n8n | The editable description is not carried. The payload's context.anomalies[].description field holds the failed check messages as plain text instead. |
In a Flow message, the <function define_env.<locals>.anomaly_message at 0x7f6b0ef7f100> variable carries the description. When an anomaly has no description, it carries the failed check messages instead. See Message.
Description and masked fields
If the failed check involved a masked field, the original value never appears in the description. The check failure message permanently shows <masked> in place of the actual value, both in the default description and in any later regeneration. To investigate the underlying value, reveal masked source records via the Source Records toolbar instead. See Masked Fields in Source Records. Note that the source-record view uses ***MASKED*** as its placeholder, distinct from the <masked> marker in anomaly descriptions.
Archived anomalies are read-only
Once an anomaly is archived (status Resolved, Duplicate, Invalid, or Discarded), the pencil and sparkle icons no longer appear on the anomaly details view. To edit the description through the UI, restore the anomaly first; see Restore Anomalies.
Timeline tracking
Every description change is recorded in the anomaly's Timeline section, alongside status changes, tag updates, assignee changes, and comments. Each entry shows:
- The user who made the change.
- The timestamp of the edit.
- The previous value and the new value, so you can see exactly what changed.
See the Timeline section of the Anomaly Insights page for details on the timeline.
Permissions summary
| Action | Required permission on the anomaly's datastore |
|---|---|
| Read the description | Reporter team permission |
| Edit the description | Author team permission |
| Suggest a description with AgentQ | Reporter team permission + AgentQ configured on the deployment |