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.
"Every weekday at 7:30, check the status of project KG-2041 and give me a short summary, but only if it is delayed or on hold."
Without the condition, Atlas would send the operations lead a summary every weekday morning, even when KG-2041 is on track. With it, she hears only when it matters.
Before you start
- Read Create an Automation and Schedules.
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 | In the KG-2041 example |
|---|---|---|
| Description | The condition in words, for people to read. | "Only deliver a summary when project KG-2041 is delayed or on hold." |
| Rules | Up to 5. Each rule compares one value with a target. | project_status contains delayed; project_status contains on hold |
| Logic | All rules must hold, or any one of them. | Any of |
A rule has a value checked (what to look at, with a short description), a comparison, and a value to compare with. In the preview Atlas wrote the first rule as: project_status (text) contains delayed — The project's current status.
| 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 custom API, a SQL Database Reader, 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. For the KG-2041 check, Atlas calls its get_project_status API (see Connect Your API) and reports the status it gets back, for example "Delayed".
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 value without having read any data, the report is refused and it has to read the data first. It may never estimate or reuse a value 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 value, it cannot check the condition. Test the exact question in the chat first, for example "What is the status of project KG-2041?". If the agent can answer it, it can check it.
What each result does
| Result | What happens |
|---|---|
| Met | The task runs, then the actions. KG-2041 is "Delayed", so Atlas writes the summary. |
| 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. Atlas says this in the preview: "If the condition cannot be checked, the result is delivered anyway." 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 preview-and-confirm step again.
Examples
| The user says | Condition |
|---|---|
| "…but only if KG-2041 is delayed or on hold." | project_status contains delayed, or project_status contains on hold (logic: any) |
| "…if any project waits more than 5 business days at one approval stage." | Business days at current approval stage > 5 |
| "…if there are more than 3 open safety incidents at the Surabaya site." | Open safety incidents at Surabaya > 3 |
| "…if KG-2041 is delayed and more than 60% of the budget is spent." | project_status contains delayed, and Budget spent % > 60 (logic: all) |
The second and third examples need a tool that can read approval stages and safety incidents, for example a SQL Database Reader on Kirana's project database. The Projects API from the Connect Your API tutorial returns one project's status, progress, budget and approval stage, so it covers the first and last examples.
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 …".
Check the result
In the automation preview, check that:
- The Condition line says in words what the user meant.
- Each rule uses a value the agent can really read, and the right comparison ("contains" for a status text,
>for a count). - The logic (any or all) matches the user's "or" or "and".
Next steps
- Next in the journey: Actions, WhatsApp and Email, to choose what happens with the result.
- How Automation Works: where the condition check happens during a run.