One filter. Every surface.
This is the least visible thing about UnifyLoop and the one that changes your week. A saved view, a campaign segment, an automation’s if-condition, and a lead-scoring rule are not four features that resemble each other. They are one filter definition hitting one engine.
- Filter dialects in the product
- One
- Surfaces sharing it
- Views, segments, automations, scoring
- Relative dates
- Resolved when it runs
- Permission enforcement
- In the engine, not per screen
Why your current CRM has eleven filter builders
Large CRMs grew feature by feature, and each team that needed filtering built its own. So the list-view builder supports “is empty” but the workflow condition doesn’t. The segment builder understands relative dates but the scoring rules don’t. Nothing is broken exactly. It just means the answer to “can I filter on that?” is always “which screen are you on?”, and you keep rebuilding the same logic in slightly incompatible dialects.
Define it once, then point it at anything
Because there is exactly one filter format and one compiler, a definition is portable. Build “customers with no activity in 30 days” as a view you check each morning, then reuse the same definition as the audience for a re-engagement campaign, the entry condition on an automation, and tonight’s call list in the dialer. Change the definition and every view, segment, and automation using it updates, because they were never separate copies.
- Relative dates like “this month” resolve when the filter runs, not when you saved it
- Group and sort without leaving the view
- Share a view with your team, or keep it private
- Lead-scoring rules are filters with points attached, so a score always explains itself
- The same engine applies record visibility by role, so nobody sees a record through a view they couldn’t open directly
- Filter across related records, not just fields on the object in front of you Coming soon
Fast because it compiles, not because it caches
Filters compile straight to SQL against Postgres rather than being evaluated row by row in application code. Fields that get filtered on heavily get their own indexes, so a view over hundreds of thousands of records stays interactive instead of degrading into a spinner and a “try narrowing your search” message.
Why does one shared filter engine matter to me as a buyer?
Two reasons you feel directly. You learn filtering once instead of four times, and logic you build stays reusable instead of being re-entered per feature. The second reason is that capability arrives evenly: a new filter operator shows up in views, segments, automations, and scoring rules on the same day.
Can I filter on fields of a related record?
Not yet, but it’s coming soon. Today a filter works on the fields of the object you’re filtering, including owner, stage, dates, and any custom field. Because every surface shares one engine, related-record filtering will arrive in views, segments, and automations at the same time.
What happens to a campaign when I edit the segment it uses?
Segments keep themselves current, re-checking every couple of minutes, and automations listening for “entered segment” react as people qualify. A campaign takes its audience at the moment it launches, so editing a segment afterwards never changes who an already-sent campaign reached.
Can the AI write filters for me?
Not yet. Plain-language search that writes a real, saveable filter is coming soon. Today the AI works on a single record or conversation: summaries, a health read on a deal, a suggested next step, and drafted replies.
Step 2 of the customer journey.
Try it on your own data.
Free workspace, contacts and pipelines ready at signup, and every price published. No mandatory call.
Free plan · No credit card · Every price on the site