The Brain Behind the Action
You’ve learned theTrigger-Condition-Action model for automation, and you’ve learned the grammar of UQL. This article explains how the two are fundamentally connected: UQL is the engine that powers the Condition block.
This integration is what transforms your automations from simple, static rules (“always send an email”) into intelligent, data-driven workflows that can adapt to changing information (“only send an email if the deal is high-value”).
UQL in the ‘Condition’ Block
This is the primary way UQL and Automation work together.- How it Works: When a 
Triggerfires, the automation rule uses a UQL query in theConditionblock to evaluate the triggering🧊 Object. If the UQL query returns ‘true’ for thatObject, theActionsproceed. If not, the rule stops. - Simple Example: For a rule triggered by a 
Dealupdate, the conditiondeal_value > 100000 AND status = 'PROPOSAL_SENT'ensures the automation only runs for high-value, active deals. - Advanced Example: For a rule on a 
ProjectObject, the conditionclient.priority_support = trueuses dot notation to check a field on a relatedClientObject, creating a context-aware automation. 
For a complete, step-by-step guide on all the operators and syntax for writing these conditions, please see our definitive guide:
→ Deep Dive: Building Conditions with UQL
→ Deep Dive: Building Conditions with UQL
UQL in the ‘Action’ Block (Advanced)
Beyond the Condition block, UQL also plays a critical role in someAction steps. When an action needs to find or update other 🧊 Objects, you can use UQL to specify exactly which Objects to act upon.
- Use Case:
- Trigger: A 
ProjectObjectis moved to theARCHIVEDstatus. - Action: Select the “Update other Objects” action.
 - UQL in Action: Use the query 
parent_project = {{object.key}} AND status != 'DONE'to find allSub-Tasksthat are related to the archived project and are not yet done. You can then add a subsequent action step to update the status of all these found tasks toCANCELLED. 
 - Trigger: A