PRD · ATLAS-PRD-0142

Saved Views & Filters (Atlas)

In review v0.4 draft Priority P1

Author

Priya Natarajan · PM, Workspaces

Last updated

2026–06–09

Target release

2026.7 (July)

Eng lead

Marco Feldt

Design

Hana Okafor

Stakeholders

Data, Mobile, Support, GTM

1Summary#

Atlas lets teams filter the work list by assignee, status, label, and date. Today those filters reset the moment you navigate away. Saved Views & Filters lets a person name a filter set, pin it to the sidebar, and share it with their team so a view becomes a stable, returnable place rather than something rebuilt on every visit.

This spec covers the create, edit, share, and pin lifecycle for views on the project work list. It does not change the underlying query engine. Mobile gets read-only parity in the first release with full editing deferred to a fast follow.

2Problem#

From 41 support conversations and 12 user interviews in Q1, three patterns are consistent:

Filters are ephemeral. A filter set lives only in the URL of the current tab. Reloading, switching projects, or opening Atlas on another device drops it. Power users keep filter combinations in a notes doc and paste them back in.
Teams cannot align on one view. Standups, triage, and sprint reviews all want everyone looking at the same slice. Today the host reads filter settings aloud so others can replicate them by hand.
The default list is noisy. New members land on every task in the project and have no obvious way to narrow to "my open work this week," which lowers first-week activation.

We measure success against a baseline where the median active user re-applies the same three filter combinations 6.2 times per week.

3Goals & non-goals#

Goals

What we will deliver

Save the current filter set as a named, returnable view.
Pin views to the project sidebar for one-click access.
Share a view with a team or the whole project.
Read-only view access on mobile web and apps.
Reduce repeat filter re-application by 40% for active users.

Non-goals

Explicitly out of scope

New filter operators or fields beyond what exists today.
Cross-project or workspace-wide saved views.
Scheduled view digests or email reports.
View-level permissions beyond project membership.
Mobile view editing (deferred to 2026.8).

4User stories#

US-1 · Contributor

As an engineer, I want to save "My open bugs, this sprint" so I can return to it each morning without rebuilding the filter.

US-2 · Team lead

As a team lead, I want to share a "Triage queue" view with my team so everyone works from the same prioritised list.

US-3 · New member

As someone new to a project, I want to discover the views my team already relies on so I can orient without asking.

US-4 · Manager

As a manager, I want a pinned "At risk this week" view so my status check is one click rather than a setup ritual.

5Requirements#

Functional requirements for the first release. Each carries a priority tag.

Save current filters as a viewP0
A user can convert the active filter set into a named view from the filter bar. Name is required, 1–60 characters, unique within scope.
Pin and reorder viewsP0
Pinned views appear under the project in the sidebar and can be reordered by drag. A user may pin up to 12 views.
Edit and update a viewP1
Editing filters on an open view shows an unsaved-changes indicator with Update view and Save as new actions.
Share scopeP1
A view is Private, Team, or Project. Only the owner or a project admin can change scope. Default is Private.
View directoryP2
A searchable directory lists all views visible to the user, grouped by scope, with owner and last-used metadata.
Mobile read-only parityP1
Shared and pinned views render correctly on mobile. Editing controls are hidden, not broken.
Deep-linkable viewsP2
Each view has a stable URL that restores its filter state and respects the viewer's access scope.

6UX flow#

Primary path: a user turns an ad-hoc filter into a shared, pinned view.

Step 1

Filter

User narrows the work list with existing filters.

Step 2

Save view

Names the set; picks an icon and scope.

Step 3

View appears in the project sidebar.

Step 4

Team members see and open the same view.

The save dialog reuses the existing modal pattern. Scope selection sits inline so sharing is a deliberate, single choice rather than a separate flow.

7Acceptance criteria#

The feature is shippable when all of the following hold. Checked items are verified in the current build.

Saving a view from an active filter set persists name, scope, and all filter parameters.
A pinned view opens its exact saved filter state from the sidebar.
Changing filters on a saved view surfaces an unsaved-changes state with update and save-as-new paths.
Switching a view from Private to Team makes it visible to all team members within 2 seconds.
Mobile renders shared views read-only with no broken or dead editing controls.
A user without project access opening a view URL receives a clear no-access state, never partial data.
The view directory loads within 400 ms p75 for projects with up to 200 views.

8Open questions#

OQ-1 · Ownership on offboarding

When a view owner leaves the project, does a Team or Project view transfer to a project admin, or become read-only and orphaned? Leaning toward auto-transfer to the project admin.

OQ-2 · Pin limit

Is 12 pinned views the right ceiling, or should it scale with project size? Needs a look at sidebar density before we commit.

OQ-3 · Naming collisions

If two teams in a Project-scoped view both want "Triage queue," do we disambiguate by owner, by team, or block the duplicate? Pending Design input.

9Rollout plan#

Phase	Audience	Gate to advance
Internal	Atlas staff	No P0/P1 bugs open for 5 business days; save and pin verified end to end.
Beta flag	~30 design partners	Repeat-filter rate down at least 25% vs. baseline; qualitative sign-off from 5 partners.
GA 10%	10% of projects	Error rate within 0.1% of control; directory p75 under 400 ms.
GA 100%	All projects	One week stable at 10%; Support volume flat or down; mobile parity confirmed.

Each phase is gated behind the saved_views flag. Rollback is a single flag flip; saved views remain in storage and re-appear on re-enable.

10Appendix#

›Data model & persistenceAPX-A

A view is stored as a row keyed by view_id with project_id, owner_id, scope, name, icon, and a serialized filter_spec JSON blob. The filter_spec mirrors the existing query DSL, so no migration of the query engine is required.

Pins are a join table view_pins(user_id, view_id, sort_order) so pin state is per-user even on shared views.
last_used_at is updated on open and powers directory sorting and offboarding heuristics.
Scope changes write an audit entry for Support to trace visibility issues.

›Analytics & instrumentationAPX-B

We track view_saved, view_pinned, view_opened (with a source of sidebar, directory, or link), and view_scope_changed. The north-star is the repeat-filter reduction; the guardrail is sidebar interaction depth, which should not regress.

Funnel of interest: filter applied → save dialog opened → view saved → view re-opened within 7 days. We expect the largest drop between dialog opened and saved, and will iterate on the naming step if it exceeds 35%.

11Changelog#

Version	Date	Author	Change
v0.4	2026–06–09	P. Natarajan	Added rollout gates, mobile read-only scope, and three open questions after eng review.
v0.3	2026–05–28	P. Natarajan	Reworked requirements into prioritised list; added view directory as P2.
v0.2	2026–05–19	H. Okafor	Added UX flow and save-dialog scope decision.
v0.1	2026–05–12	P. Natarajan	Initial draft from Q1 research synthesis.