Behind every automation there is a mental model – and the clearer that model is, the easier it is to work with. 1Tool relies on a simple yet flexible building-block principle: trigger, condition, action. These three types of building block form the framework from which every automation in the visual editor is assembled – no matter how simple or complex the use case turns out to be in the end.
The trigger: what starts the automation
Every automation begins with a trigger, i.e. an event that occurs in the system and sets the workflow in motion. The trigger is therefore the first node you define when creating an automation – alongside the name and description of the automation itself. The specific triggers available are not hard-coded into the editor but loaded dynamically from the system, complete with name and description. So you choose from a selection that adapts to your 1Tool environment, instead of having to make do with a fixed list that is identical for every customer.
The condition: control instead of autopilot
Not every automation should react in exactly the same way every time the trigger event occurs. This is where conditions come in. They are attached to the trigger as separate nodes and decide whether and how the workflow continues. Conditions, too, are provided by the system with name and description, so the automation editor adapts flexibly to the logic that actually exists in the system. Importantly, a condition does not have to lead to exactly one next step. It can have several possible child steps – so depending on the outcome of the condition, the workflow branches in different directions instead of rigidly following a single line.
The action: the actual effect
At the end of every path is the action – the step that actually makes something happen. Actions are also nodes on the canvas, likewise loaded from the system with name and description, and they are connected to the preceding trigger or condition node. Because trigger, condition and action exist as separate building-block types that can be combined freely, the result is not a rigid set of rules but a construction kit: you combine the elements as your specific business process requires, instead of squeezing it into a ready-made template.
Why a construction kit is more flexible than a template
Rigid templates only ever cover the standard case they were designed for. As soon as the process changes, they quickly reach their limits. The trigger-condition-action principle, on the other hand, provides building blocks rather than finished solutions: the same block types can be recombined, extended or adapted for completely different workflows – directly in the visual editor, visible as connected nodes on the canvas instead of hidden away in configuration text.
Frequently asked questions
Do I need a condition for every automation?
No, conditions are an optional building block. An automation can in principle consist of just a trigger and a directly connected action.
Can a condition lead to several different actions?
Yes. A condition can have several possible child steps, which means the workflow branches in different directions depending on the result.
How do I know which triggers, conditions and actions are available to me?
The editor loads each of them with name and description directly from the system, so you can see in the editor itself which building blocks can currently be selected.
Would you like to see the trigger-condition-action principle in action on your own processes?