"I just need it in a spreadsheet" is one of the most common sentences in any organization that works with data. An accountant wants to reconcile the quarter's invoices against the bank statements, and the reconciliation tool wants a spreadsheet. A manager wants to share a snapshot of this month's pipeline with someone who doesn't have access to the platform, and email with a spreadsheet attachment is the lingua franca. An analyst wants to pivot, filter, and crosstab in ways the platform doesn't natively offer, and the spreadsheet is where that work happens. A platform that makes exports trivial on every view — with the right columns, in the right formats, without failing on large selections — is a platform users trust with their data.
Every view exports. Table views, list views, kanban boards, calendar views — if you can see it in the platform, you can hand it to a spreadsheet. The export button is consistent across viewers, so users don't have to learn a different mechanism for each type of view. For tables, where exports are used most often, the interaction is one click: the current view, the current filters, the current grouping, all reflected in the output.
Columns follow the view. The export respects the column configuration of the view that produced it. If the user has hidden three columns, reordered the rest, and pinned two important ones to the left, the spreadsheet matches what they're looking at. That sounds obvious and it's the opposite of obvious — many platforms export a platform-wide default set of columns that has little to do with the view on screen, forcing users to re-do in the spreadsheet what they already did in the viewer. We treat "what you're looking at" as the specification for "what you want to export," which is usually right.
Per-property export formatting handles the small details that make a spreadsheet usable when it arrives. Dates appear as dates, not as ISO strings that Excel might or might not re-interpret. Numbers appear as numbers, with the right decimal places. Choice-property values render with their human labels rather than internal identifiers. Currency amounts retain their currency context. References to other records render as the referenced record's display value, with the option to include an identifier column for further processing. These decisions are made per property, following the same rendering logic that controls on-screen display, so the spreadsheet matches what the user already sees.
Special-format values are the escape hatch for properties whose on-screen representation isn't the right shape for a spreadsheet. A status pill with an icon and a color is a helpful on-screen widget; in a spreadsheet, it should be a plain text value. A progress bar shown as a graphic should export as a percentage. A tags property might export as a comma-separated list even if on screen it's a collection of colored chips. Each property type knows how to represent itself for export, and that representation is what lands in the file.
Raw vs. display values gives the choice back to the user when it matters. An export for further processing in a data tool benefits from raw values — identifiers, full precision numbers, non-localized dates — because downstream tooling prefers consistent machine-readable content. An export for reading benefits from display values — formatted currencies, translated labels, localized dates — because humans prefer the version that looks right. Both modes are supported; the user picks whichever fits their task.
Large result sets are handled through the background-job path. An export of ten thousand rows is a tedious operation that would, on a naive implementation, either time out, exhaust memory, or lock the user's session for a minute. The platform recognizes large exports and moves them to the background: the user clicks export, gets a notification that the export is running, and keeps working. When the job completes, a notification drops into their inbox with a link to the finished file. This is one of those features that's invisible for small exports and genuinely essential for big ones.
Export-all option covers the common case where the user wants everything in the result set rather than just the current page. A view that's paginated to fifty rows still has a "export all" button that pulls the full query, streams through the result set in a memory-safe way, and produces the complete file. For reporting workflows that need "the whole dataset, not just what I can see on screen," that option is what the user is actually looking for.
Pluggable exporters are the extensibility story for cases where the default output shape isn't quite right. A tenant might need an export formatted to a specific template required by an external regulator — particular columns, particular headers, particular value formats. Implementers can register custom exporters that produce the exact shape required, selected at export time alongside the default. The custom exporter uses the same query and the same data, but lays it out according to its own rules. That's how edge-case export requirements get handled without forcing everyone else into a more complex default.
Export promises close the loop between the user's intent to export and the finished file. The moment the user clicks export, the platform commits to producing the file; the user can close the tab, navigate to another record, do completely unrelated work, and the export still completes. The resulting file appears in notifications when ready, with a direct download link. For large exports that take several minutes, this is the difference between an export feature that's usable and one that requires users to babysit a loading spinner.
Exports aren't glamorous. They're one of those features that every platform has, most of them badly, and the difference between a good implementation and a bad one only shows up at the moments users care about most — the end of the quarter, the audit, the urgent request from the CEO for "that list, now." We've treated exports as first-class and invested in the parts — column fidelity, large-set handling, format control, custom exporters — that make the difference. For the rest of the data-handling story, the views article covers how users see their data, the table view article covers the primary export surface, the data-import article covers the matching path in the other direction, and the file repository article covers where large exports can be stored for later access.