# Filtered project export

Illustrative PRD. All research inputs, thresholds, targets and project details are fictional teaching examples, not customer evidence or measured results.

## Problem and evidence

Workspace admins need to export a filtered project list for a weekly review. In this fictional example, research note I-01 describes copying rows into a spreadsheet and I-02 describes sharing too much information. These are invented teaching inputs. No research finding or baseline is a real customer result.

## Outcome and measurement

Enable an authorized admin to download only the filtered rows they can access. Track export_started, export_completed and export_failed with a request ID and row count, excluding row contents. Establish the baseline during a pilot. A proposed target is 95% successful export attempts for supported datasets. Product owns the decision to continue after pilot review.

## Scope and non-goals

First release supports manual UTF-8 CSV exports of up to 5,000 matching projects from one workspace. Include project ID, title, status, owner and target date. Exclude private notes, scheduled email exports, cross-workspace joins, PDFs and custom columns. The 5,000-row limit is a fictional product decision requiring engineering validation.

## Users and permissions

Workspace admins can request an export. The server checks current membership and row visibility when producing the file. A viewer receives an access-denied response. If access is revoked after the page loads, the export is denied. A user-provided workspace ID never establishes permission.

## Requirements and acceptance criteria

R-01 applies the current workspace and server-validated filters. R-02 checks permission at export time. R-03 writes a valid UTF-8 CSV and neutralizes formula-like cell values for spreadsheet use. R-04 rejects datasets above the limit with a clear next step to narrow filters. R-05 handles empty results and failed requests without displaying a success message. The acceptance table below defines how to review these requirements.

## Experience and edge cases

Place Export CSV beside the project filters. Show the selected filters before confirmation. Disable repeat submission while a request is active. For no matching projects, show an empty-state explanation and preserve filters. For more than 5,000 rows, request narrower filters. After a network failure, show Retry and keep the original selection. Do not display a stale file from a previous export as the current result.

## Dependencies and feasibility

Engineering must verify that the project query can enforce row visibility and stream the supported dataset within the deployment limits. Security reviews exported fields and formula neutralization. Design reviews status messages and keyboard access. If the supported request cannot complete reliably, revisit an asynchronous job design before implementation approval.

## Risks and mitigations

Data disclosure is a release blocker. Security must test revoked membership, hidden rows and tampered workspace IDs. Spreadsheet formula execution is a release blocker until representative dangerous values are neutralized and tested in the supported spreadsheet applications. Unexpected load requires a smaller limit or a revised export design.

## Rollout and release decision

Run acceptance and permission tests in staging with synthetic data. Pilot with an internal workspace, then an explicitly selected small customer cohort. Product and engineering review failure rate and support feedback before expansion. Disable the export entry point and server operation if any unauthorized data appears. Retain the existing project workflow during investigation.

## Open questions and change history

Q-01 asks whether project owners should be exported by display name or stable ID. Product and privacy review must decide before development approval. Q-02 asks whether the row limit is feasible under production request limits. Engineering must answer before estimating. Draft v0.1 is dated November 9, 2026. A later request for scheduled exports requires a new scope decision and a review of R-01 through R-05.

## Acceptance review

### R-01
Export the current server-validated project selection.
Given two workspaces and a status filter, the file contains only visible projects from the selected workspace that match that filter.
Filter state alone cannot establish which rows the server returns.

### R-02
Enforce current export permission.
A viewer, an admin whose access was revoked, and an altered workspace ID are denied. No file content is returned.
The permission check belongs to the export operation.

### R-03
Produce spreadsheet-safe CSV cells.
Quotes, commas, newlines and formula-like text round-trip as data. Test opening representative exports in the supported spreadsheet applications.
CSV quoting and formula neutralization solve different problems.

### R-04
Enforce the agreed row limit.
The 5,000-row boundary succeeds. A 5,001-row request explains how to narrow the filter and never silently truncates.
Silent truncation gives reviewers an incomplete record.

### R-05
Make outcomes and recovery clear.
Empty, denied, oversized and interrupted requests show their own outcomes. Retry preserves selection and never reports a failed export as complete.
A visible success state must correspond to a completed operation.

## Reading and review
Adapt this original teaching template to your team. Guidance checked November 9, 2026.
https://www.atlassian.com/agile/product-management/requirements
https://owasp.org/www-community/attacks/CSV_Injection