Filter with rules

Rules run on every message before delivery. Each has a condition and an action: when this matches, then do that.

Where: Flow → Rules.

With no rules, every message passes straight through — which is fine until you notice how much of your traffic is status callbacks nobody wants.

Rules run top-down

Order matters. Rules evaluate from the top, and the first match decides what happens.

Stop at this rule when it matches ends evaluation there. Without it, evaluation continues and a later rule can still apply.

Put your most specific rules first. A broad rule at the top will shadow everything below it.

Conditions

A rule matches ALL of its conditions or ANY of them. Each condition is a field, an operator and a value:

messageType       equals        DATA_BIDIR
decoded.battery   less than     10
decoded.index     exists

The field is a dot-path into the message, so decoded readings are reachable as decoded.<name>. Available operators cover equality, presence, numeric comparison, and set membership.

Both the field and the value are pickers. The field list offers everything a rule can read:

Fields with a closed set of values — provider, messageType, ack, callbackType, and any true/false your decoder returns — offer those values rather than asking you to remember the spelling; in and not in let you pick several. Anything else is free text, and you can always type a field by hand: a decoded path only appears in the list once a message has been decoded through this source.

Actions

Deliver

Send the message on. Optionally restrict it to specific sinks — choose none and it goes to all of them.

This is how you split traffic: alerts to the on-call webhook, routine readings to the billing platform, from one source.

Drop

Discard the message. It is not delivered anywhere.

The most common first rule anyone writes. Sigfox status, acknowledge, repeater and error callbacks carry nothing your billing system wants, and dropping them early keeps the noise out of every sink at once.

Respond with a downlink

Answer the device synchronously. See Respond with a downlink.

Wait / correlate

Hold this message until a related one arrives, then deliver them together. Two modes:

Fragment collection is what makes multi-frame payloads work: a reading too large for one transmission arrives in pieces, and your sink should see one complete reading rather than three unusable partials.

Both modes take a timeout, and a choice of what to do when it expires — deliver what arrived, or drop it. Pick deliberately: partial data can be worse than no data, depending on what the receiver does with it.

A worked example

A water meter deployment, in rule order:

Rule 1 removes the noise and stops. Rule 2 raises an alert but does not stop, so rule 3 still runs and billing gets its reading too. A low battery produces two deliveries, which is what you want — the alert is extra, not instead.

Turn on Stop in rule 2 and billing would silently lose every low-battery reading. That is the single easiest mistake to make here.

Reordering and disabling

Drag rules to reorder them. To take a rule out of service without losing it, deactivate it — an inactive rule stays stored and is skipped at evaluation.

Deactivating is better than deleting while you are diagnosing something. You can put it back in one click.

When messages vanish

If traffic is received but never delivered, a rule dropping it is the first suspect. Work down the list in order and check which one matches first — and remember a Stop earlier in the list may be preventing a later rule from ever running.

Next