Query

The Query data type is used to define logical rules. It is different from Text, Number, Date, or Table types because it represents a condition, not a stored value. A Query tells Monkedo how to compare two pieces of data and decide whether a rule passes or fails.

The Query data type appears only in some components, but its most important usage is inside the Condition component.

When building automations, the Condition component allows your workflow to make decisions. You define one or more Query rules; each rule gets its own output port on the Condition block. When the automation runs:

• If a rule matches, the automation follows that rule's named output (for example, "Today" or "High Priority").

• If none of the rules match, the automation follows the Otherwise output.

There is no single "True" or "False" path. You can add as many named conditions as you need, plus the shared Otherwise fallback.

A Query rule is made of three parts:

1. Input — the value you want to check. (Example: task status, price, name, date, email subject)

2. Comparison — what type of check you want to perform. (equal, contains, greater than, empty, etc.)

3. Value — the thing you compare the input to. (Example: "Completed", 100, "urgent", "2027-01-01")

Comparison Options

• equal — passes if the input is exactly the same as the value.

• not equal — passes if the input and value are different.

• greater than — passes if the input is greater than the value.

• greater than or equal — passes if the input is greater than or equal to the value.

• less than — passes if the input is smaller than the value.

• less than or equal — passes if the input is smaller than or equal to the value.

• contains — passes if the input includes the value anywhere inside it.

• not contains — passes if the input does not include the value.

• in — passes if the input matches one item in a list of values.

• not in — passes if the input does not match any item in a list.

• empty — passes if the input exists but has no value.

• no empty — passes if the input has any value.

• set — passes if the field exists.

• not set — passes if the field does not exist at all.

• starts with — passes if the input begins with the value.

• ends with — passes if the input ends with the value.

• matches pattern (regex) — passes if the input fits a regular expression.

• is alpha — passes if the input contains only letters.

• is numeric — passes if the input contains only numbers.

• is date — passes if the input is a valid date.

Common Confusions for Comparisons

empty vs. not set:

• "empty" means the field exists but is blank;

• "not set" means the field does not exist.

contains vs. in:

• "contains" searches inside text;

• "in" checks whether the input is one of several listed values.

starts with vs. contains:

Beginning of text vs. anywhere in text.

AND / OR Logic in Query

You can combine multiple comparisons to build more advanced rules.

AND Rule

All conditions must pass. Example: Price > 100 AND Category = "Electronics". Both must pass for the query to match.

OR Rule

Only one condition needs to pass. Example: Status = "Active" OR Status = "Pending". If either condition passes, the query matches.

Each named query you add to a Condition component creates a dedicated output port. When the automation runs, only one path is active at a time — either one of your named condition outputs, or Otherwise if no rule matched. Connect downstream components only to the outputs that should run for each case; do not merge outputs that cannot be active simultaneously.