> ## Documentation Index > Fetch the complete documentation index at: https://help.the-meridian.ai/llms.txt > Use this file to discover all available pages before exploring further. # Variable matches a value A variable condition branches a flow on one [variable](/automation-variables): the store's plan, its revenue, a value the trigger carried, one of your custom fields. It's the finer-grained sibling of the [segment condition](/condition-segment). ## Configuring it Three parts: the **variable**, the **comparison**, and, for most comparisons, a **value**. | Comparison | Reads the value? | | - | - | | Equals · Does not equal | Yes | | Contains · Does not contain | Yes | | Is empty · Is not empty | No, tests the variable alone | Comparison is **case-insensitive and ignores surrounding spaces**, so `Pro` matches `pro `. The panel summarises the wiring in a sentence (runs take the Yes branch when the variable matches, the No branch otherwise), so there's no guessing which handle is which. ## Which variables you can pick The picker offers up to three groups: * **Store variables**, available on every trigger, resolved from the store the flow is running for. * **Trigger variables**, carried by the event itself: `subscription_plan`, `charge_name`, `event_quantity` and the rest. * **Event properties**, on the two triggers with a metered event behind them, [Custom event is tracked](/usage-event-tracked) and [Usage view crosses a threshold](/usage-view-threshold-crossed): the [properties](/automation-variables#event-properties) your app sends with the event. A trigger variable only exists on the triggers that carry it. Variables the current trigger doesn't provide are shown as *not available* rather than hidden, and choosing one blocks activation with "a condition uses a variable this trigger does not provide", because at runtime it would resolve to empty and the branch would be meaningless. ### Event properties When the trigger names **one** event, the picker lists the properties that event's recent rows actually carried, each with the share of them holding it: `total_price · on 100% of recent events, e.g. 512.5`. It's a sample of your history, so it tells you up front what a skip counter would otherwise tell you afterwards. On **Custom event is tracked** that is the custom event the trigger watches. On **Usage view crosses a threshold** it is the event the chosen [view](/usage-views) reads, since a view is defined over exactly one event key. Pick neither and the picker has nothing to sample, so you type the property instead. It is a sample, not a rule. **Use another property…** takes any property path you type, which is the case that matters when the release you're shipping starts sending something your history has never held. Nothing about the sample gates saving or activation. An event property has **no declared type**: its shape is yours, and the same property can arrive as a number in one release and a word in the next. So every comparison is offered, and the one you pick is what says how the value is read: | Comparison | Reads the property as | | - | - | | Is greater than · Is less than · Is between | A number | | Is before · Is after · Is in the last N days | A date | | Is true · Is false | `true` / `false` | | Contains · Does not contain · Is one of | Text | | Equals · Does not equal | A number when both sides are numbers, text otherwise, so `500` matches `500.00`, and `Pro` matches `pro` | | Is empty · Is not empty | Presence alone | A value the comparison can't read never matches: **is greater than 500** against `"expensive"` takes the No branch rather than erring. And a bound the comparison can't read is refused at activation: you can't activate a flow comparing a number against a word. **Contact variables can't be used here.** Conditions are evaluated before a recipient is known, so a per-recipient value has nothing to resolve against; they exist in the email editor only. ## Empty values A variable the trigger didn't carry resolves to an empty string, which is exactly what **is empty** tests. That's the honest way to branch on "did this event carry a plan name at all" instead of comparing against a blank string. This is how a missing event property behaves too, and it's deliberate: an absent `properties.total_price` is never treated as `0`. The condition takes the **No** branch, negative comparisons included. Silence is not disagreement. ## Deleted variables Custom fields join the variable catalog as `custom_field_`. Delete the field and the condition references a variable that no longer exists, so the builder flags it and blocks activation. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.