6.1 Exporting Question Results: CSV, Headers, Flatten Rows and Copy
Key Takeaways
- Question results export to CSV, either for selected rows or for the complete results, with an optional Include headers in export setting that writes the sensor names as column headers.
- By default the exported file puts all of a sensor's results for one endpoint into a single row, while selecting Flatten rows produces one row per result.
- Flatten rows works only if just one sensor in the question returns multiple results per endpoint, because two multi-value sensors cannot be paired unambiguously.
- Fail on errors causes the whole export to fail if any result has multiple columns with more than one value, and it is disabled by default so the export proceeds with unflattened rows.
- Copy places grid rows on the clipboard as comma-separated value strings, and Copy Cell Value copies a single cell, which suits human recipients rather than automated processing.
6.1 Exporting Question Results: CSV, Headers, Flatten Rows and Copy
Quick overview: Blueprint objective RPT-1 asks you to determine the correct method to export required data for use outside of the application. Tanium gives you three distinct methods with different shapes, and choosing wrongly produces a file that is technically an export and practically useless. Copy puts rows on the clipboard, Export writes a CSV, and Connect delivers data to a system on a schedule (section 6.4).
1. Copying results to the clipboard
For a quick paste into a message, a text file or a spreadsheet, copy directly from the Question Results grid. Each row in the grid becomes a comma-separated value string in the copy.
| To copy | How |
|---|---|
| Specific results with the sensor names as column headers | Select the corresponding checkboxes and click Copy |
| The contents of a single grid cell | Hover over the cell, click Options, then Copy Cell Value |
Copy is the right tool when the destination is a human — a ticket comment, a chat message, an email to a colleague. It is the wrong tool for anything that will be processed, because nobody can audit where a pasted table came from.
Selecting rows efficiently
To select multiple consecutive rows for copying, exporting, drilling down or deploying actions: click the checkbox in the first row, hold Shift, and click the checkbox in the last row.
2. Exporting to CSV
Export writes the same columns you see in the grid to a CSV file, readable by any application that supports the format — Excel, for example, to build charts from the data.
The workflow
- Choose the scope:
- Specific results — select the checkboxes and click Export.
- The complete results — click Export in the header of the grid.
- Enter a File Name for the CSV file.
- Optionally select Include headers in export to write the sensor names as grid column headers into the file.
- If you are exporting the complete results, configure the multi-result options below.
- Click Export.
[!IMPORTANT] Steps 4's options appear only when exporting the complete results. If you selected a subset, you click Export and you are done — which also means you have no control over how multi-result rows are shaped. If the row shape matters, export the complete results.
Flatten rows: the option that decides whether your file is usable
Some sensors return multiple results per endpoint. Tanium's own example: Get Computer Name and High CPU Processes[5] from all machines returns five processes for each endpoint.
| Setting | File shape |
|---|---|
| Default (not flattened) | One row per endpoint, with all of the sensor's results for that endpoint together in the row. For the example, each row lists all five top processes for that computer |
| Flatten rows | One row per result. For the example, five rows per endpoint — one for each process the sensor returned |
Which you want depends entirely on the consumer:
- A human reading a summary → the default. One line per machine is readable.
- Anything that will be pivoted, filtered, counted or loaded into a database → Flatten rows. A spreadsheet cannot group by a value that is buried inside a composite cell.
A hard constraint: flattening works only if just one sensor in the question has multiple results. If two sensors both return multiple values per endpoint, there is no unambiguous way to pair them into rows.
Fail on errors
Selecting Flatten rows reveals a Fail on errors checkbox.
| Setting | Behaviour when an endpoint returns multiple values in more than one column |
|---|---|
| Fail on errors selected | The export fails for all results if any result includes multiple columns with more than one value |
| Fail on errors cleared (default) | The export proceeds despite such errors. The output includes the errors without flattening the affected results — those rows do not get separate lines to account for multiple columns with multiple values |
The choice is between a file you can trust completely and a file you definitely get:
- Select it when the file feeds an automated process, a compliance submission, or anything where a silently malformed row would be worse than no file.
- Leave it cleared for exploratory work, where getting most of the data now beats getting all of it later.
3. Choosing the right export method
| Requirement | Method |
|---|---|
| Paste a handful of rows into a ticket or chat | Copy |
| Grab one value | Copy Cell Value |
| One-off analysis in a spreadsheet | Export to CSV, default row shape |
| Feed a pivot table, a script or a database load | Export to CSV with Flatten rows |
| Guarantee the file is not silently malformed | Export, Flatten rows, Fail on errors selected |
| Deliver the same data every day, unattended, to another system | Connect (section 6.4) |
| Repeatable analysis that colleagues will reuse in Tanium | A report (section 6.2), not an export |
[!TIP] The last row is the judgement the exam is really testing. Exporting the same CSV every Monday is a reporting requirement wearing an export costume. If the answer to "who will do this next month?" is "me, again, by hand", build a report or a Connect connection instead.
4. Practical cautions
- An export is a snapshot. Question results expire after 10 minutes (30 for TDS-registered sensors), and the CSV is a point in time with no built-in record of which endpoints were unreachable.
- Reissue before you export. A stale grid produces a stale file that nobody can tell is stale.
- Only what you can see is exported. Results come only from endpoints in computer management groups assigned to your account or persona, so two operators exporting the same question produce different files. Note the scope alongside the file.
- Offline endpoints are absent, not compliant. For a fleet-wide statement, use Reporting rather than exporting a live question grid.
- Include headers unless you have a reason not to. A headerless CSV is guesswork three weeks later.
- Exports leave Tanium's access controls behind. Once a CSV of endpoint data is on a laptop, the content set and computer group model that protected it no longer applies. Treat exported endpoint data with the sensitivity of its contents.
An operator exports the results of 'Get Computer Name and High CPU Processes[5] from all machines' and needs the file loaded into a database with one row per process. Which setting is required?
Why can Flatten rows fail to produce the expected file when a question contains two sensors that each return multiple values per endpoint?
An export feeds an automated compliance submission where a silently malformed row would be worse than no file at all. How should Fail on errors be set, and what does that do?
Two operators export the same question on the same morning and produce files with different endpoint counts. What is the most likely explanation?