Work Management
Work Management (formerly Case Management) is a feature that tracks matters requiring a response that fall short of an incident as work items with an assignee and a status. Items raised from monitors or security signals are opened and closed within a project.
What it does
Triages, tracks, and remediates problems detected by Datadog and external integrations as work items. Each item carries an assignee, a status (open / in progress / closed), and a priority (P1 to P5), and its history is kept in an activity timeline. It integrates with Jira / ServiceNow / PagerDuty / Slack / Microsoft Teams.
When to use it
Use it to keep a record of matters that fall short of an incident yet cannot be left alone, such as "a monitor fired but it is not something to wake someone up for right now," "someone needs to look at a security signal and make a call," or "we want to track an error fix through next week." It also works as change management with approvals and as the origin for filing Jira tickets.
An everyday analogy
It is the numbered ticket and the reception ledger handed out at a government office counter. Each matter brought in gets a number and goes into the ledger, the responsible counter and processing status are added, and it is closed when done. It is a mechanism for reliably handling at the counter matters that do not warrant setting up a disaster response headquarters (an incident).
Bottom line - formerly Case Management, turning sub-incident matters into items and working them
The feature you were looking for under the name Case Management has been renamed Work Management. The official documentation states the former name at the top and notes that the word case remains in API and permission names (as of September 2026, source: Work Management). Its role is a central place to triage, track, and remediate problems detected by Datadog and external integrations. When you assign an assignee to a work item, ownership persists throughout the lifetime of that item. During investigation you attach graphs and logs to the item and collaborate in the activity timeline. Jira, ServiceNow, PagerDuty, Slack, and Microsoft Teams are listed as integration targets. Without this feature, matters that "fired but are not urgent" drift away in chat and disappear, and when the same monitor fires the next month nobody remembers how it was handled last time. With it, whose hands the matter is in, what is known, and where it was closed remain on a single screen.
The line between work items and incidents
The criterion for the line is "do you gather people and declare right now?" Events where a service is affected, a commander is appointed, and recovery proceeds with timestamped records are the domain of Incident Management, where the status progresses Active / Stable / Resolved (the details of transitions are left to that explainer). On the other hand, monitor notifications, security signals, error matters, and the like, "things someone needs to look at, judge, and follow up on, but not declare," are work items. A work item's status has 3 stages, starting at open and moving through in progress to closed, and a priority of 5 levels from P1 - Critical to P5 - Info can optionally be attached (as of September 2026, source: View and Manage Work Items). The two are not mutually exclusive; if you discover while investigating a work item that the impact is large, you can declare an incident from that item and escalate it. Conversely, you can track recurrence-prevention work that came out of a retrospective as items.
| Aspect | Work item (Work Management) | Incident (Incident Management) |
|---|---|---|
| What it handles | Triage, tracking, and remediation of detected problems | From declaring an event with ongoing impact through the retrospective |
| Status | open → in progress → closed | Active → Stable → Resolved |
| Priority / severity | P1 - Critical to P5 - Info (optional) | Severity set at declaration |
| Ownership | 1 assignee (unassigned by default) | Commander and roles |
| Connection between the two | Declare an incident from an item to escalate | Track recurrence-prevention work as items |
Where do work items come from?
There are three ways they are created: manually, automatically, and through the API. Manually, besides pressing New Work Item, you can raise them from the screens of monitors, security signals, Error Tracking, Watchdog, Event Management, Cloud Cost Management, Sensitive Data Scanner, and Slack (as of September 2026, source: Create a Work Item). Automatically, writing @case-<project_handle> in a monitor's notification message creates an item at every alert, and items are also created from Event Management correlation, the Create Case action in Workflow Automation, and actions on Error Tracking issues. Items carry a work type, and there are Standard, Change Request, Event Management, Security, Error Tracking, and custom types.
- Enable Datadog Monitors under Integrations in the project settings and obtain @case-<project_handle>
- Write that handle in the monitor's notification message
- At every alert, a work item is created automatically in that project
- Assign an assignee, move the status to in progress, and attach the graphs and logs you examined
- Set it to closed, or declare an incident if the impact is large
What an item contains: status, priority, assignee, and timeline
A single item holds a status, a priority, an assignee, and an activity timeline. The status is open at creation, priority and assignee are unset by default, you change them with the S, P, and A keys on the keyboard, and I assigns the item to yourself. Archiving removes it from search. The activity timeline automatically records updates to status, assignee, priority, signals, and comments with timestamps, and people mentioned by name in comments receive an email (as of September 2026, source: View and Manage Work Items). What pays off is that the record remains as a byproduct of the operations. Nobody takes minutes during a response, but the fact that the status was changed and the graphs that were attached remain. Furthermore, Work Management Analytics is a data source you can query for aggregates of items, and you can draw them with widgets such as timeseries, top lists, query values, tables, and pie charts in dashboards and notebooks. "Of the items opened in this project last month, how many were closed within a week" becomes a graph.
Escalation to an incident, and the division of roles with Jira and ServiceNow
An item has 5 exits: declaring an incident, creating a Jira issue, creating a ServiceNow incident, requesting approval, and closing it by setting it to closed (as of September 2026, source: View and Manage Work Items). The question that is easy to get stuck on regarding the division with external tickets is "if we have Jira, do we even need Work Management?" The official documentation explains, regarding the integrations with Jira, ServiceNow, and Linear, that you can resolve items using Datadog telemetry while also keeping the investigation record in those external systems, and Jira supports configuring automatic ticket creation and bidirectional sync (source: Settings). The choice is not either-or; it is a design that separates "the place to investigate" from "the system of record." If you divide it so that the work of attaching graphs and logs and chasing the cause is on the Datadog side, and cross-department approvals and ticket number management are on the existing ticketing platform, the sync absorbs the double entry.
| Exit | What happens | Suitable situation |
|---|---|---|
| Declare an incident | Raises an incident from the item and starts the response process | You discovered while investigating that the impact is broad |
| Create a Jira issue | Besides manual creation, you can configure automatic creation and bidirectional sync | The development team's work management lives in Jira |
| Create a ServiceNow incident | Manually files a ticket on the ServiceNow side | IT service management records are kept in ServiceNow |
| Request approval | Asks one or more reviewers for approval and records the result in the timeline | Change management requires confirmation before execution |
| Close | Sets the status to closed and ends it | You judged that no further action is needed |
Projects and permissions, and automatic closing of neglected items
An item belongs to one project. A project is a container with a key of 1 to 10 characters, and item IDs use the key as a prefix, like NOC-123. The key cannot be changed, and deleted items cannot be restored (as of September 2026, source: Projects). Permissions have 4 levels, Manager, Contributor, Viewer, and No Access (unrestricted by default). Automatic creation from other products happens regardless of permissions. As a countermeasure against neglect, there is a setting that automatically closes items with no human action (attribute updates or comments) for 7, 14, 30, 90, or 180 days, evaluated once a day (source: Settings). The approval feature asks one or more reviewers for agreement, and Requested / Approved / Declined remain in the timeline (source: Work Item Approvals). Organization-wide history is the domain of the Audit Trail; an item's timeline is a record confined to that matter.
What changes when small responses are kept on record
Three things change. First, recurrence becomes visible. If items are created from the same monitor every week, the problem is the threshold or the mechanism, and lining up the counts in Analytics turns the discussion into numbers. Second, handoffs. Because the assignee and the investigation history remain in the timeline, when people change due to vacation or transfer, the next person can pick up where they left off. Third, change management. Using the Change Request type and the approval feature, "who approved and executed it" can be traced afterward. Its role differs from the domain of paging: if On-Call is the mechanism for "waking someone up right now," Work Management is the mechanism for matters that "can wait until tomorrow but must not be forgotten." This article does not show a unit price for it; check the public price table and your account contact. The thinking behind seat-based billing for Incident Management, which sits in the same lineup, is in the pricing section of that explainer, and the overall pricing structure is summarized in the pricing guide.
Things to watch out for
- Work Management is annotated in the official documentation as of September 2026 as "formerly named Case Management." The word case continues to be used in API endpoints, permission names, and the monitor handle (@case-<project_handle>).
- This article is based on the official documentation as of September 2026. Source products and work types may be added, so check the list in the official documentation.
- This article does not show a unit price for Work Management. Check contract terms in the public price table and with your account contact.