A builder made of trigger, condition and action is abstract at first — the real question is what it can do in the everyday work of a CRM or ERP system. Since the triggers, conditions and actions actually available are loaded from the system and can differ from one 1Tool environment to another, no fixed catalogue can be given here. The following points are therefore deliberately meant as food for thought — as examples of the direction in which such a builder is typically used, not as a list of built-in features.
Notifications at the right moment
One conceivable example would be an automation that automatically triggers an internal notification when a certain event occurs in the system — for instance when a record reaches a particular state that a team wants to keep an eye on anyway. This could prevent relevant events from slipping through the cracks simply because nobody was actively looking for them. Whether and in what form such a trigger actually exists in your 1Tool environment depends on the specific options the editor shows you.
Routing to the person in charge
Another conceivable scenario would be a workflow that, depending on a condition — such as a characteristic of a case — automatically routes it to the responsible person or department. Instead of every incoming case having to be reviewed and assigned manually, the condition could take over the assignment and the action could trigger the routing. This would be an example of how responsibilities can be handled by rules rather than by hand — the actual implementation depends on which conditions and actions your system provides.
Automated follow-up steps on status changes
A further illustrative example: when the status of a case changes, an automation could respond with one or more follow-up steps — for instance by informing the people involved or by performing another internal action. Because conditions can branch in the 1Tool editor, different status changes could also lead to different follow-up steps, instead of creating a separate automation for every case.
Recurring checks and reminders
Finally, a workflow would also be conceivable that regularly checks whether certain conditions are met and, if necessary, sends a reminder or initiates a next step. This could prevent cases from lying unattended for long periods. Here too, the editor shows you directly whether a suitable trigger is available for such a use case — with the name and description of each option.
The builder adapts to your system
What all four examples have in common is that they are not meant as fixed features, but as patterns showing how trigger, condition and action can be combined. Which building blocks are actually available to you in the editor becomes clear when you create a new automation — all options are loaded from the system there, with their name and description. The real value of the builder lies in the fact that you assemble these building blocks yourself instead of being limited to a predefined set of automations.
Frequently asked questions
Are the examples mentioned automations that are built into 1Tool? No, they are illustrative examples of how such a builder could be used. The editor shows you directly which triggers, conditions and actions are actually available. How can I tell what is actually possible in my 1Tool environment? When you create an automation, all available triggers, conditions and actions are loaded from the system with their name and description and displayed in the editor. Can I combine several of these examples in a single automation? Since conditions can branch and have several child steps, different cases can in principle be handled in one coherent workflow. Would you like to go through together which automations are actually possible in your 1Tool environment?
