Skip to main content

​
Overview

A Saved View captures the current filters (and, depending on the page, the selected columns, sort order, items per page, and scoring period) on the Contact List, Company List, People List, or Master List page as a named, reusable view. Applying a saved view instantly re-applies everything it captured. A Trigger is optional and layers on top of a saved view built from the Contact List, Company List, or People List. When enabled, it pushes every record matching the view’s filters to a webhook URL — once as a backfill, then continuously as matching records are created or updated. Reporting v2 has its own, separate “Smart Views” for saving filter/date-range presets on the analytics dashboard — those don’t send data anywhere. See Reporting v2 for that feature. This page covers Saved Views on the record list pages and the webhook Triggers built on top of them.
Creating, editing, and configuring triggers on a Saved View is restricted to users with the admin role. Any signed-in user can apply an existing saved view from the sidebar to filter a list.

​
Creating a Saved View

1

Set up the list the way you want it

Apply filters (and, on Contacts/Companies/People, choose columns, sorting, items per page, or a scoring period) on the Contact List, Company List, People List, or Master List page.
2

Save it

Click Save View above the list, then Save as new view. Give it a name and an optional description.
3

Set visibility

Choose who can see the view and, for client-scoped pages, which clients it applies to (see below), then save.
The same Save View menu also has Update current view, which overwrites the currently-applied saved view with the list’s current state instead of creating a new one. It’s disabled until a saved view is active and something about the list has actually changed. What gets saved depends on the page: Admins can also create and edit saved views from the dedicated Saved Views page (/dashboard/saved-views), which lists every view you have access to with its visibility, trigger status, and row actions (edit, trigger settings, stats, delete).

​
Visibility

Every saved view has two independent visibility settings: Master List views hide the Client Accounts axis entirely when you create them — only the Users axis is shown. Under the hood, though, the view is still saved against whichever client is currently selected elsewhere in the app and defaults to the “only this client” scope, so in practice a Master List view can end up visible only while that same client is selected, not agency-wide as the hidden axis might suggest. When creating a Master List view, only Only you and All admins are offered on the Users axis (not All users); that restriction isn’t re-applied if you later edit the same view’s visibility from the admin Saved Views page.
Narrowing Client Accounts on a view that has a trigger also narrows who the trigger can send to. Any per-client webhook URL for a client that falls out of scope is dropped the next time the trigger settings are saved.

​
Using saved views from the sidebar

Saved views you have access to appear in a dedicated Saved Views section of the left sidebar. From there you can:
  • Search — the search box filters the list by name.
  • Reorder — drag views to reorder them; the order is saved per user and persists across sessions.
  • Apply — click a view to instantly filter the current list (or navigate to the matching page and apply it) using everything the view captured. Click it again to clear the view and return to an unfiltered list.
  • A view you just created shows a New badge for the rest of the current session (it clears on your next page load, not when you view it).
Admins see an additional + button (enabled only on Contacts, Companies, People, Reporting, or Master List pages) to save the current view, and a pencil icon that opens the admin Saved Views page. On the admin Saved Views page, Add Recommended Views seeds a small set of default views for the currently selected client — for example a “Do Not Contact” view, a “Recently Added” view, and a couple of others for both contacts and companies. It skips any recommended view whose name you’ve already used for that client, so it’s safe to click more than once.

​
Triggers

A trigger turns a saved view into a live webhook feed: every record that matches the view’s filters gets POSTed as JSON to a destination URL, and the feed keeps running as matching records change. Triggers are only available on saved views built from the Contact List, Company List, or People List — the sync icon in the saved views table is disabled for any other view type (including Master List). Open trigger settings from the sync icon on a view’s row in the admin Saved Views page. The dialog is titled Trigger settings.

​
Configuring destinations

Trigger destinations are per-client webhook URLs, one per client in the view’s visibility scope:
  • Each client in scope gets its own text field for a webhook URL.
  • A blank URL means that client receives nothing. You don’t have to send to every client a view is shared with.
Leaving a client’s URL blank isn’t just “skip for now” — every record currently matching the view is immediately marked as already sent for that client the moment the trigger is enabled, exactly as if it had actually been delivered. If you fill in that client’s URL later, none of the records that matched before you added it will be backfilled — only records that start matching afterward go out. To get a real backfill for a client you add later, disable the trigger, add the URL, and re-enable with Full Sync & Ongoing (disabling clears the sent/waiting state for every client on the view, not just one).
  • A counter above the list shows how many of the in-scope clients currently have a URL configured (e.g. “3 of 12 clients”).
  • When a view is scoped to more than 8 clients, a filter box appears to search the client list by name.
  • If the view predates per-client destinations (it used to carry a single shared URL for every client in scope), that URL is automatically copied into every in-scope client’s field the first time you open the dialog — you don’t lose the old configuration, but you do need to re-save to persist the per-client values.
While a trigger is enabled, its destination URL fields become read-only. To change a client’s webhook URL, disable the trigger first, edit the URL, then re-enable it.
If the saved view’s visibility currently resolves to zero active clients (for example, a client-scoped view whose client was archived), the dialog shows an info banner instead of any URL fields: “This saved view is not shared with any active client, so it has nowhere to send. Change the client access under Visibility first.”

​
Delivery settings

Expand Delivery settings to configure:
  • Daily limit — a send cap shared across every client destination on this view (default 100,000/day). It’s enforced on the backend; once the count for a given day is hit, further sends for that view are rescheduled for 1am the next day rather than dropped outright (up to 3 reschedule attempts before RevyOps gives up on a given send).
  • Sync mode — only shown while the trigger is disabled, since it only applies at enable time:
    • Full Sync & Ongoing — backfills every currently-matching record to its client’s destination, then keeps sending new matches as they appear.
    • New Records Only — skips the backfill. Every record that already matches the view’s filters is marked as already sent without actually being sent, so only records that start matching after you enable the trigger go out.

​
Sending a test event

Each destination row has a send icon. Clicking it POSTs an example JSON payload to that client’s URL immediately, without needing the trigger enabled — useful for confirming your endpoint is reachable and parses the shape correctly before you turn on live sync. A success or failure message appears below the destination list. Click Example payload to expand a preview of exactly what gets sent for this view’s type. The shape differs by view:
  • Contact List views send a single contact object (id, email, name, company_id, contact_custom_fields, status history, campaign send/reply timestamps, etc.).
  • Company List views send a single company object (id, domain, name, status, company_custom_fields).
  • People List views send a single person object — a person can have multiple emails, so emails is an array (each with its own job title, status, and campaign timestamps), plus linkedin_urls, phones, custom_fields, and the person’s score/live_score.

​
Enabling and disabling a trigger

Enabling requires at least one client destination to be configured — the Enable trigger button stays disabled otherwise. Both enabling and disabling require typing a confirmation word (ENABLE or DISABLE) into a text field before the action button becomes clickable, as a guard against accidentally toggling a live data feed.
  • Enabling saves the current destinations/settings, then kicks off a backend job that evaluates the view’s filters and starts sending — as a one-time backfill plus ongoing sync (Full Sync & Ongoing), or ongoing-only (New Records Only), per the sync mode you picked.
  • Disabling stops the feed and clears the per-record dedupe state RevyOps kept for that view, so if you re-enable later with Full Sync & Ongoing, everything currently matching is treated as new and gets sent again.

​
How ongoing sync decides what to send

Once a trigger is enabled, RevyOps re-evaluates it whenever a relevant record is created or updated — through the API, CSV import, a connected platform webhook (Instantly, SmartLead, HubSpot, Close CRM, etc.), or LinkedIn activity. A record is only sent once per saved view: RevyOps tracks a sync status (WAITING/SENT) per record, per view, so the same record isn’t re-delivered on every subsequent update. If a previously-matching contact or company stops matching the view’s filters, its tracked status is cleared, so it’s treated as new again if it re-enters the view later.
People List triggers behave slightly differently here: a person’s sync status is never cleared once set. If a person leaves and later re-enters a people-list view’s matching set, they are not re-sent.
Updating a contact also re-evaluates triggers on its related company and person, and vice versa — so a contact-list trigger can fire from a change made on the company record, and a company-list trigger can fire from a change on one of its contacts. Saved views whose filters include a date-based condition (a relative or fixed date range) are additionally re-evaluated automatically once a day, since matches for those views can change purely from time passing — a “last 7 days” filter, for instance, needs no record change to gain or lose matches.

​
Viewing trigger stats

The Stats icon (row action or the button inside the trigger settings dialog, enabled once the trigger is on) opens a slide-over showing:
  • Total records synced and total failed sends, for the selected date range.
  • Timestamp of the first event ever sent for this view.
  • A day-by-day chart of successful vs. failed sends, with a date range picker (defaults to the last 10 days).

​
Permissions summary

​
Troubleshooting

  • “This saved view is not shared with any active client, so it has nowhere to send.” The view’s client visibility currently resolves to no active clients. Go back to the view’s Visibility settings and widen the client scope.
  • Enable trigger stays disabled. You need at least one client destination filled in first — an empty destination list can’t be enabled.
  • A destination URL field won’t let me type. The trigger is currently enabled; destination URLs are read-only while live. Disable the trigger, edit the URL, then re-enable.
  • A client I added a webhook URL to never received its backfill. If that client’s URL was blank when the trigger was first enabled, every record matching at that time was baselined as already sent for that client. Disable the trigger, confirm the URL, and re-enable with Full Sync & Ongoing to get a real backfill.
  • Sends stopped going out mid-day. The view’s shared daily limit was likely hit; sends past the limit are rescheduled rather than lost, and resume the next day.
  • A record was updated but never fired the webhook. Check whether it was already marked as sent for this view (records are only delivered once per view) — for People List views specifically, once a person is marked sent for a view, they won’t fire again even if they leave and re-enter the matching set.