Describe the export as a data contract
A compact review sheet can say:
| Contract | Representative value |
|---|---|
| Rows | 42 open requests matching Region = West |
| Fields | Request ID, opened date, owner, status |
| Excluded | Client email, internal notes, deleted records |
| Data as of | 2026-08-01 09:42 PDT |
| Format | CSV, UTF-8 |
| Delivery | Link available to this session for 15 minutes |
Do not replace the row rule with “current view” when the current view is paginated, sorted, grouped, or showing a cached result. State whether the export uses visible rows, explicitly selected rows, all filtered matches, or a named saved query. Sorting may affect file order without affecting membership; say which parts carry forward.
Treat rows and fields as separate authorization axes
OWASP's object-level authorization guidance explains that an endpoint receiving an object identifier must check that the current user can act on that object. Its property-level guidance warns about exposing sensitive object properties and recommends explicitly selecting returned fields.
An export endpoint needs both checks. A user may be allowed to see request R-104 but not its internal notes or client contact details. Hiding a column in the browser does not prove the export query excludes it. Rebuild the allowed row and field set on the server from the current identity, policy, and request.
Make freshness and timing explicit
The count shown during review can change before generation. Choose and name the contract:
- a snapshot taken at request time;
- the latest authorized rows when the job starts; or
- a versioned saved query with a recorded cutoff.
If generation is asynchronous, provide a request identity and state: queued, generating, complete, empty, failed, expired, or cancelled. Do not leave the user wondering whether closing the page cancels the export. Do not show a download link before the authorized artifact exists.
Report the result, not merely the request
On success, show actual row and field counts, data timestamp, format, file size when useful, and expiry. On an empty result, state whether no authorized rows matched rather than silently downloading a blank file. On failure, say that no file was created—or that the result is unknown—and provide a safe retry or support path.
W3C status-message guidance applies when progress and results appear without a focus change. Use a programmatically determinable status and keep important completion details visible. W3C labels guidance also supports explaining required acknowledgement or scope inputs rather than relying on an icon or file-format abbreviation alone.
Acceptance checks
- The review identifies visible, selected, or filtered row membership exactly.
- Every active filter and important exclusion is readable in text.
- The field list distinguishes included and intentionally excluded properties.
- The data cutoff and whether counts can change are explicit.
- The server recomputes object and property authorization for the export.
- The request has a stable identity and duplicate activation policy.
- Queued, generating, complete, empty, failed, and expired are distinct states.
- Success reports actual rows, fields, timestamp, format, and expiry.
- Download URLs and files follow the stated access and expiration behavior.
- Audit and retention requirements are supplied by the data owner, not invented by the interface.
This pattern does not establish compliance or endpoint security. It makes the export contract inspectable enough that data, security, product, and accessibility reviewers can test the same promise.