Conditions
A condition is an optional check that runs after the trigger fires and before the task starts. It answers: "Is there anything worth doing right now?" If not, the run stops quietly.
"Check the SLA of all branches every morning. If any is below 80%, analyze the cause and send it to my WhatsApp."
Without the condition the agent would message the user every morning whether or not anything was wrong. With it, the user hears only when it matters.
Structured rules, not guesses
The user describes the condition in words; the agent turns it into structured rules that Qlar evaluates itself. A condition has:
| Part | Detail |
|---|---|
| Description | The condition in words, for people to read. |
| Rules | Up to 5. Each rule compares one value with a target, for example SLA < 80 or Region = "Jakarta". |
| Logic | All rules must hold, or any one of them. |
A rule has a value checked (what to look at), a comparison, and a value to compare with:
| Kind of value | Comparisons |
|---|---|
| Number | <, ≤, >, ≥, =, ≠ |
| Text | =, ≠, contains, does not contain |
| Yes / No | =, ≠ |
Numbers are read forgivingly — 1.000.000, 80% and 80,5 are all understood.
Where the data comes from
The agent itself reads the data — with the tools and skills your agent already has, such as a SQL Database Reader, a custom API, or its knowledge base. On each run it fetches the current value, reports it to Qlar, and Qlar decides met or not met. The agent does not decide whether the condition holds; it only reports what it found.
Two rules protect against wrong answers:
- The value must come from a real tool result in this run. If the agent tries to report a figure without having read any data, the report is refused and it has to read the data first. It may never estimate or reuse a number from an earlier conversation.
- A value that cannot be read is reported as unknown, not invented.
This means a condition is only as good as the tools behind it. If your agent has no tool that can read the figure, it cannot check the condition. Test the exact question ("What is the SLA of each branch today?") in the chat first — if the agent can answer it, it can check it.
What each result does
| Result | What happens |
|---|---|
| Met | The task runs, then the actions. |
| Not met | The run stops. No conversation is created and no WhatsApp message is sent. It is recorded in the history as Condition not met — which is normal, not a failure. |
| Unknown | A condition existed but a value could not be read. It is treated as met, so the user is not left without news. If this happens three times in a row, the user gets a warning notification to check the automation. |
| No condition | The automation has none; the task runs every time. |
Editing a condition
On the user's Automations page a condition can be reworded, re-targeted, or removed. It cannot be added or replaced with a different check there — for that the user asks the agent in a conversation, which goes through the summary-and-confirm step again.
Examples
| The user says | Condition |
|---|---|
| "If any branch's SLA is below 80%…" | SLA < 80 |
| "Only if the balance exceeds 1 billion…" | Balance > 1000000000 |
| "If the Jakarta region has more than 5 open tickets, or any ticket is critical…" | Open tickets > 5, or Critical tickets > 0 (logic: any) |
| "If there is stock below the minimum in any warehouse…" | Lowest stock margin < 0 |
Keep conditions simple. Up to five rules combined with all/any covers most needs; anything more complicated is better handled in the task itself — ask the agent to "analyze and only report if …".