Anomaly Assignees
This page covers the behavior of the Assignees field on an anomaly. For step-by-step actions, see Add Anomaly Assignees, Remove Anomaly Assignees, and Bulk-Assign Anomalies.
The field
The Assignees field on an anomaly is a list of users responsible for reviewing and resolving it. An anomaly can have zero, one, or many assignees, and any user with at least the Viewer role on the datastore can be selected. In the Summary section of the anomaly details, the first assignee's avatar is shown, with the names of assignees beside it. With one or two assignees, all names appear. With three or more, only the first assignee's name appears, followed by +N for the remaining count. A +N badge sits beside the avatar whenever an anomaly has more than one assignee; hovering the badge shows the remaining assignees.
The field is independent from the anomaly's status, description, and tags: assigning a user does not change any of those, and changing those does not change the assignees. The only automatic write to this field happens at creation, as described in Inheritance from the originating check below.
Inheritance from the originating check
Every quality check has a single Default Anomaly Assignee field, available on both Authored and AI Managed checks. For details, see Anomaly Assignee on the check editing guide. When a new anomaly is created from a check that has a default assignee set, that user is automatically added as the initial assignee of the anomaly.
A few details worth knowing:
- Anomalies can have many failed checks. When the anomaly is generated from 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 if check A defaults to user Alice and check B defaults to user Bob, an anomaly produced from both checks is created with Alice and Bob as assignees.
- Inheritance happens only at creation. Changing a check's default assignee later does not retroactively re-assign anomalies that have already been created. Existing anomalies keep whatever assignees they have until someone edits them.
- Checks without a default contribute nothing. Only failed checks that have a default assignee add users to the list. If every failed check behind an anomaly has no default, the anomaly is created with no assignees.
Permissions
| Action | Required permission on the anomaly's datastore |
|---|---|
| See the Assignees field | Viewer |
| Be selectable as an assignee | Viewer |
| Add or remove assignees | Author |
When editing, the user picker lists every user that has at least the Viewer role on the datastore. Users without access are filtered out by the platform and cannot be assigned even by an Author. See Team Permissions for the full role matrix.
Archived anomalies are read-only
Assignees of archived anomalies (status Resolved, Duplicate, Invalid, or Discarded) cannot be changed. Restore the anomaly first (it returns to Acknowledged) before editing assignees.
Notifications
Whenever an anomaly's status, tags, description, or assignees change, the platform creates an Assignment in-app notification for every user currently listed as an assignee, except the user who made the change. The notification has the form:
updated an anomaly you're assigned to
#<anomaly id>•
Clicking the notification opens the affected anomaly.
A few specifics:
- Self-edits do not notify. If you edit the anomaly yourself, you do not get a notification for that edit. Other assignees do.
- Newly added assignees are notified. When a user is added to the assignee list, they become part of the recipient set for the same update event. The notification is the first signal they receive about the anomaly.
- Removed assignees are not notified. Users who are removed from the assignee list as part of the update do not receive a notification for that update.
- Creation is silent. Auto-assignment via the originating check's default assignee at anomaly creation does not produce a notification. The first notification for a newly created anomaly fires on the next update event.
See In-App Notifications · What Triggers a Notification for how Assignment notifications appear in the bell-icon list alongside other notification types.
History tracking
Every change to the assignee list is recorded in the anomaly's History section, alongside status changes, description edits, tag updates, and comments. The timeline shows:
- Who made the change.
- When the change happened.
- Which users were added and which were removed.
- Self-assignment and self-unassignment entries are surfaced explicitly, so it is clear when a teammate took ownership of an anomaly or stepped away from it. Like other assignee edits, this requires the Author team permission on the anomaly's datastore.
See the History section of the Anomaly Insights page for how to read and comment on the timeline.
Assignees, owners, and default assignees
Three related concepts are easy to mix up. Here is how they differ:
| Concept | Lives on | Cardinality | What it does |
|---|---|---|---|
| Owner | Quality check | One user | The person responsible for the check itself. Used for filtering checks by owner and for ownership notifications. |
| Default Anomaly Assignee | Quality check | One user | The user that anomalies produced by the check are auto-assigned to at creation time. |
| Assignees | Anomaly | Many users | The users actually responsible for resolving the anomaly. Editable per anomaly. |
So the chain reads: a check has one owner and one default assignee; when the check produces an anomaly, that default seeds the anomaly's assignees list, which can then be expanded or narrowed independently.
Filtering by assignee
You can narrow the anomaly list to a specific set of users in two ways:
- The Assignees filter. A multi-select dropdown of active platform users. Selecting one or more users narrows the list to anomalies where any selected user is an assignee. Available on both the explore anomalies page and the per-datastore anomalies tab.
- The Assigned subtab inside Open. A one-click shortcut to "open anomalies assigned to me." See Open · Assigned.
Both work alongside the other anomaly filters (tags, rule type, timeframe, etc.), so you can layer them. For example, combine "assigned to me" with a specific tag or a "last 7 days" window to narrow the list further.