Filters and saved views

What saved views are for

Saved views answer recurring operating questions.

Instead of rebuilding the same filter stack every time, the team saves a view once and reuses it:

• what needs review today?
• what is still missing?
• which findings need partner attention?
• which entities are risky but still in perimeter?

If the question shows up every morning, every weekly review, or every partner check-in, it probably deserves a saved view.

Views work across four resource types:

• Projects for portfolio and pipeline tracking
• Files for evidence review
• Entities for org-structure and screening review
• Tasks for work management

The morning review queue

Example workflow: start from the same lens every day

A diligence manager opens the same saved views every morning: recent evidence, tasks with open gaps, files with critical flags, and tasks due this week. That is what turns views from a filtering convenience into an operating rhythm.

What a saved view captures

Each saved view stores:

• Filters — which records are included
• Grouping — how the list is bucketed
• Sorting — the default order
• Display settings — the fields and columns visible for that resource

That means a saved view is not just “a filter.” It is a repeatable operating lens.

A saved view shares a list configuration. The records each reviewer can see still depend on their permissions; sharing a view does not grant access to its underlying projects or files.

Common views worth saving

Question	Best saved view
What changed overnight?	Files sorted by recency
What is still unresolved?	Tasks filtered by gap state
Which issues need senior review?	Files or tasks filtered by red-flag severity
Which entities need investigation?	Included entities with risk signals
Which tasks are about to slip?	Tasks grouped by assignee and sorted by due date

How teams usually use them

Use saved views for the recurring list states that matter to the team:

• a morning review queue
• a diligence-manager view for unresolved work
• an entity-risk view for perimeter + verdicts
• a report-prep view for critical findings and gaps

Use ad hoc filters when the question is one-off. Save the view when the question comes up every day or every week.

Build the view from the decision

Start with the decision the team needs to make, then build the view backwards:

• if the question is “what changed?” sort by recency
• if the question is “what is blocked?” filter tasks to open gaps
• if the question is “what needs escalation?” filter to deal breakers and critical flags
• if the question is “who is overloaded?” group tasks by assignee and due date

Filter coverage

The exact filter menu depends on the resource type. Files, tasks, entities, and projects all expose different dimensions.

In practice, the most useful filter families are:

• Projects — status, stage, pulse, owner, dates, structure, control
• Files — category, subcategory, red flags, governing law, jurisdiction, entities, lifecycle, uploader, assignee
• Entities — risk verdict, sanctions, litigation, PEP, adverse media, IP, licences, perimeter status
• Tasks — red flags, gaps, category, subcategory, status, stage, milestone, priority, assignee, due date

That is usually enough to design the views teams actually use day to day.