Skip to content
Syncline

Filter records before they send

Conditions sit between the trigger and the action, so a flow acts on the records that matter and stays quiet on the rest. Build one, combine rules, then test it.

Updated 2026-07-15
<h2>Where a filter sits</h2><p>A filter is a step between the trigger and the action. The trigger fetches records, the filter decides which of them continue, and the action runs only on the survivors. Records that stop at the filter are logged as skipped, and a skipped run does not count against your task allowance.</p><p>That last point changes how you should build. It is cheaper and clearer to use a broad trigger with a sharp filter than to hunt for a trigger that fires exactly right, because the filter lives in Syncline where you can read it and change it in ten seconds.</p><h2>Build a condition</h2><ol><li><strong>Open the flow and click Add filter</strong> between the two existing steps.</li><li><strong>Pick a field from the trigger record.</strong> The dropdown shows the sample values beside each name, which makes it obvious whether an amount arrives as 4900 or as 49.</li><li><strong>Choose an operator.</strong> The list changes with the field type, so a number offers greater than and a text field offers contains.</li><li><strong>Type the value to compare against.</strong> Text comparisons ignore capital letters by default, and there is a checkbox if you need them to matter.</li><li><strong>Add more rules and choose how they combine.</strong> A group of rules joined with <em>and</em> must all pass. A group joined with <em>or</em> needs one. You can nest one group inside another for the awkward cases.</li><li><strong>Click Test filter.</strong> Syncline replays the last twenty five real records through the condition and shows which passed. This is the step people skip and then regret.</li></ol><h2>The operators</h2><table><thead><tr><th>Operator</th><th>Works on</th><th>Typical use</th></tr></thead><tbody><tr><td>is, is not</td><td>Text, select, number</td><td>Status is Ready for review</td></tr><tr><td>contains</td><td>Text</td><td>Subject contains invoice</td></tr><tr><td>starts with</td><td>Text</td><td>Card name starts with URGENT</td></tr><tr><td>greater than</td><td>Number, currency, date</td><td>Amount greater than 500</td></tr><tr><td>is empty, is not empty</td><td>Any</td><td>Owner is empty, so route to triage</td></tr><tr><td>changed from</td><td>Select</td><td>Deal stage changed from Proposal</td></tr><tr><td>in list</td><td>Text, select</td><td>Label in list of your three priority tags</td></tr></tbody></table><blockquote><p>Note: filters run on the values Syncline read, not on the live record. If somebody edits the record between the read and the write, the filter used the earlier value. The next run picks up the change, so the destination catches up rather than losing it.</p></blockquote><h3>Two filters worth copying</h3><p>The noise filter: on a chat trigger, require both a keyword and a channel. Teams routinely go from four hundred messages a day reaching a flow down to about six, and the six are the ones anybody wanted.</p><p>The money filter: on a payments trigger, filter on amount greater than a threshold and on status equal to succeeded. Without the second half you will alert on pending charges that later fail, which teaches everyone to ignore the channel.</p>

Was this article helpful?

Tell us what was missing and we will fix it.

Send feedback

Related

map-fields-between-two-apps, how-tasks-are-counted, build-your-first-flow

All help articles