Skip to content
Evergrowth Documentation

Saved views and your working lists

A saved view is a slice of your book of business that you name once and return to whenever you want. You build a list - the qualified accounts in one vertical, the persona-fit contacts you can actually reach, the accounts that have gone quiet - and instead of rebuilding those filters every morning, you save the slice. From then on it is a working list: one place you open to see exactly the records that matter for a given job, kept current as the underlying data changes.

What it is

Section titled “What it is”

A saved view captures a set of filters on the accounts or contacts list, together with the columns you chose to show, under a name you pick. Each view belongs to one list type - accounts or contacts - and a view always returns the live records that match its filters right now, not a frozen snapshot. As qualification verdicts land, research fills in, and reach data is found, the same view shows the up-to-date slice without you touching the filters again.

A view is more than a saved query. It carries a description so its purpose is obvious, an owner who created it, and it can be shared with named colleagues so a whole team works from the same definition of a list. Views you use constantly can be marked as favourites, and related views can be filed into groups so a territory or a campaign has its own shelf.

Why it matters

Section titled “Why it matters”

Most sales teams rebuild the same list over and over. A rep reconstructs “my qualified accounts in fintech, with a buying committee mapped” by hand each week; a manager rebuilds the territory view from memory; everyone’s idea of “the priority list” drifts apart. The work of defining the slice gets repeated, and worse, it gets repeated slightly differently each time.

A saved view turns that repeated effort into a one-time decision. The definition lives in one place, so the slice is consistent every time anyone opens it. Because a view is shared, “the inbound list” or “the at-risk accounts” means the same thing to the rep, the manager, and the AI colleagues working alongside them. And because the slice is recounted on a regular cadence, a favourite view doubles as a quiet monitor: its running total, together with how that total has moved over the last day and the last week, tells you when new records have crossed into the slice - more accounts qualified, more contacts became reachable - without you running anything.

A view is also a workflow input

Section titled “A view is also a workflow input”

The same slice you work by hand is a slice your automation can act on. When you build a workflow that routes records down different paths, a branch decides who goes where based on whether records match a set of conditions. Rather than rebuilding those conditions from scratch inside the builder, you can prefill a branch from a saved view of the matching list type, so the condition starts from a slice you have already defined and trust. See Workflow branching for how that works in practice.

This is the point where saved views stop being a convenience and become part of how the workspace runs: define a slice once, work it as a list, hand it to a playbook or a workflow, and the definition stays in sync across all three. You are not maintaining three copies of “the priority accounts” - you are maintaining one.

How it fits together

Section titled “How it fits together”
  • A saved view is built from the accounts and contacts filters - it is those filters, named and kept.
  • A favourite view carries a running total of matching records, plus how that total has moved over the last day and the last week, so your most-used lists double as a pulse on your pipeline. The total is refreshed on a schedule rather than recomputed on every glance, so it can trail the live list by a short while.
  • A workflow branch can prefill its conditions from a saved view, so a list you trust becomes the test that routes records.
  • The slice a view describes is what you hand to a playbook or workflow to run.

Eva: Term mapping. The customer term is “saved view”; internally this is the saved-filter mechanism on the Accounts and Contacts lists. A view stores filters plus the chosen columns, scoped to one list type (account or contact). “Assigned” views are shared with named colleagues; “groups” are folders of views; a “favourite” view shows on the dashboard with a match total plus a last-24-hours and last-7-days delta. Those totals come from a periodic count, not a live query (the product itself notes a delay of up to about an hour), so the total can trail the live list. The workflow condition step’s prefill only offers views matching the branch’s entity type, and only views built on advanced filters can prefill a branch (a basic-filter view cannot). This page owns the why - link to /how-to/save-filter-views for the clicks and to /how-to/workflow-branching for the prefill mechanic rather than re-explaining either.

In practice

Section titled “In practice”

A RevOps lead defines three views on Monday: qualified accounts in the two priority verticals, persona-fit contacts with a verified email or phone, and accounts that have not been touched in a quarter. They share each one with the named-accounts team and mark them as favourites. The reps now open the same lists the lead built, the counts tell everyone when new records arrive, and when the lead later builds a workflow to research the stale accounts, the relevant branch is prefilled from the “not touched in a quarter” view - the same slice, reused, with nobody rebuilding a filter.

Section titled “Related”