n8n Filter-nod: ta bort objekt som inte uppfyller villkor utan att splitta flödet
Filter-noden är IF-nodens syskon — men med en viktig skillnad: den delar inte upp flödet. Den bevarar de items som uppfyller villkoren och kasserar resten. En utgång. Inga parallella grenar att hantera.
Skillnaden mot IF-noden
IF-noden tar in N items och skickar ut alla N — antingen till “true”-utgången eller “false”-utgången. Du måste hantera båda grenarna.
Filter-noden tar in N items och skickar ut M ≤ N. Items som inte uppfyller villkoren existerar inte längre i flödet. Den falska grenen finns inte.
Välj Filter när du vill arbeta med en delmängd. Välj IF när du vill göra olika saker med olika delmängder.
Konfigurera villkor
Villkorsgränssnittet är identiskt med IF-nodens. Du väljer fältnamn, jämförelseoperator och värde. Tillgängliga typer:
- String: is, is not, contains, starts with, ends with, regex
- Number: equals, greater than, less than, between
- Boolean: is true, is false
- Date & Time: before, after, between
- Array: contains, length equals
Typ-mismatch-fällan gäller precis som i IF-noden: om du ställer in en Number-jämförelse mot ett fält som innehåller en sträng misslyckas villkoret tyst och inget item passerar. Kontrollera alltid din input-data med ett körtest innan du driftsätter.
AND vs OR
Lägger du till flera villkor kan du styra hur de kombineras:
AND-läge (standard): ett item passerar bara om alla villkor är sanna. Striktare. Används när du vill vara säker på att datat är fullständigt och korrekt.
OR-läge: ett item passerar om minst ett villkor är sant. Används när du vill fånga in flera likvärdiga fall — t.ex. status är “completed” ELLER status är “approved”.
Vad händer om inga items passerar?
Om alla items filtreras bort skickar Filter-noden ut en tom array: []. Det innebär att efterföljande noder körs utan data — i praktiken exekveras de inte alls i iteration-läge.
För de flesta workflows är det önskat beteende. Om du däremot behöver logga att “inga items passerade” eller skicka ett Slack-meddelande: lägg till en Error Trigger eller en separat kontrollgren efter att ha använt IF-noden istället, och lyssna på det tomma flödet.
Vanliga användningsfall
Webhook-filtrering. Din webhook lyssnar på alla events från en tjänst, men du vill bara bearbeta “completed”-orders. Lägg en Filter-nod direkt efter webhook-noden med villkoret status equals completed. Allt annat kasseras.
API-svarsrensning. Du hämtar en lista med poster från ett API. Vissa saknar e-postadress. Lägg en Filter-nod: email is not empty. Bearbeta bara de poster som har ett giltigt e-postvärde.
Deduplicering (partiell). Filtrera bort poster där processed_at redan är satt. Det eliminerar dubblettbearbetning utan att du behöver ett externt state-store.
Vanliga frågor
Kan Filter-noden filtrera baserat på om ett fält finns eller saknas?
Ja. Använd “String → is not empty” för att kräva att fältet finns och har ett värde. Eller “Boolean → is true” om fältet är en boolean-flagg.
Vad händer med items som inte passerar — kan jag spara dem?
Inte via Filter-noden ensam. Om du behöver hantera icke-matchande items, använd IF-noden istället och koppla den falska utgången till en separat logikgren.
Kan jag använda uttryck (expressions) i filtervillkoren?
Ja. Du kan använda {{ $json.fieldName }} och {{ $now }} precis som i IF-nodens villkor. Dynamiska jämförelser (t.ex. jämför mot ett värde från en tidigare nod) fungerar via Expression-läget.