Cases and Records both help you organize information, but they solve different problems. This article explains the difference in plain terms, walks through examples, and gives you a simple rule of thumb for choosing between them.
Here's the distinction to keep in mind:
Cases are a workspace for work that people do. Cases are where a team tracks, enriches, and resolves things like alerts, investigations, exceptions, or follow-ups.
Records are a structured data store. Records are tables of data you define yourself, ready for your workflows and cases to read from and write to.
Put another way: Cases are the work people own, while Records are the data you keep and reference.
When to use Cases
Use Cases when people need to track and resolve something over time. Cases give you the structure to coordinate that work, including:
Status and priority. Every case has an open or closed status, optional sub-statuses, and a severity so you can tell urgent work from routine work.
Assignees. You can assign cases to the people who own them.
Notes, files, and blocks. The body of a case holds rich notes, attached files, and other content that captures what's happening.
Tasks. You can break the work into a checklist of tasks.
A timeline. Comments, status changes, and other activity are recorded automatically, giving you a full history.
SLAs. You can track how long cases should take to resolve.
Example: a phishing alert investigation
Someone reports a suspicious email, and an analyst needs to look into it. This is a natural fit for Cases. You open a case with a high priority, assign it to the analyst, and attach the email headers and a screenshot as files. The analyst adds notes as they investigate, works through tasks like "check sender reputation" and "quarantine affected mailboxes," and the timeline records each step. When the investigation is done, they close it.
When to use Records
Use records when you need a structured table of data rather than a piece of work. With records, you define a record type (the table), give it fields (the columns), and add rows of data. There's no assignee, status, or timeline, because records hold data, not work.
Records are a good fit for things like:
Inventories, e.g., a list of assets, applications, or employees.
Lookup and reference lists, e.g., approved vendors or office locations.
Enrichment sources, e.g., threat intelligence your stories check against.
Example: a list of known malicious domains
Say you want a maintained table of known-bad domains. You create a record type called "Malicious domains" with fields for the domain, the date it was first seen, a confidence score, and the source. Each domain is a row. Your stories can query the table to check whether a domain appears in it, or write to it to add a newly discovered domain. It's data your automation relies on, not something a person opens and closes.
How Cases and Records work together
Cases and records aren't separate worlds. You can link a record to a case so the relevant data lives right alongside the work.
Continuing the phishing example: while investigating, the analyst finds the email links to a domain that already exists as a row in your "Malicious domains" record type. You can link that record to the case, and it appears in the records section of the case. Access follows the link, too. People who can see a case can see the records attached to it, even if they don't otherwise have access to the full record type. This means you can bring the right context into a case without opening up your whole dataset.
A simple rule of thumb
When you're deciding between the two, ask what you're actually holding:
Choose Cases when people need to track, enrich, and resolve something over time.
Choose records when you need a structured table of data that your stories and cases read from and write to.
And remember you can use both together: keep your reference data in records, do the work in cases, and link the two so the right information is always at hand.