Automatic Tasks
How many steps can a task have?
Botize has a limitation of only 10 steps in each task to avoid bad practices in automation design, such as excessive complexity. This limitation is made to force dividing a complex problem into simpler automations. In this way, the maintenance of an automation is simpler, there is less tolerance for errors and it is also easier to determine anomalies if they occur.
However, this limitation does not prevent creating large tasks with many steps. You can, from within a task, call others and thus end up creating larger automations. Instead of creating a task with 100 steps, you can create 10 tasks of 10 steps each, which makes it easier to understand and debug the process. This helps keep the automation clean and organized, making maintenance and problem resolution easier.
More information: Simplifying and reusing tasks.
However, this limitation does not prevent creating large tasks with many steps. You can, from within a task, call others and thus end up creating larger automations. Instead of creating a task with 100 steps, you can create 10 tasks of 10 steps each, which makes it easier to understand and debug the process. This helps keep the automation clean and organized, making maintenance and problem resolution easier.
More information: Simplifying and reusing tasks.
Can I create tasks where different steps are executed depending on different circumstances?
Yes, through rules. In each step of a task, you can define rules to be executed or not depending on certain circumstances.
Here you will find several examples explained step by step: RULES: What to do and when.
Here you will find several examples explained step by step: RULES: What to do and when.
What is Mustache and how to use it in Botize?
Botize supports the use of Mustache templates in texts, allowing you to create dynamic content based on the tags from previous steps in a task.
You can insert the value of a tag by simply writing its name inside curly braces. For example:
Control conditional logic:
Mustache allows you to use conditional blocks to display text or other values depending on whether a tag exists or has a value. For example:
This block will print "See image:" along with its corresponding URL only if the image_url tag has a value.
This block will print "No image available." if the image_url tag does not exist or is empty.
Advanced conditional content creation:
By combining tags and blocks, you can generate more complex text tailored to the circumstances of each task.
What can you do with Mustache?
Reference tags from previous steps:You can insert the value of a tag by simply writing its name inside curly braces. For example:
{{image_url}}Will display the value stored in the image_url tag.Control conditional logic:
Mustache allows you to use conditional blocks to display text or other values depending on whether a tag exists or has a value. For example:
{{#image_url}}See image: {{.}}{{/image_url}}This block will print "See image:
{{^image_url}}No image available.{{/image_url}}This block will print "No image available." if the image_url tag does not exist or is empty.
Advanced conditional content creation:
By combining tags and blocks, you can generate more complex text tailored to the circumstances of each task.
What happens when I delete a task in Botize? Can I recover a deleted automation?
When you delete a task in Botize, it is permanently removed. While it is not possible to recover deleted tasks, you can always back up all your automations at any time from your user area.
Can I share or copy tasks between different Botize accounts?
Yes, in the Account section, you will find the "Export" button, which allows you to export all your Botize tasks, and the "Import" button, which lets you import them. This way, you can export your tasks both to keep a backup and to import them into a different Botize account.
What happens if a step of my task fails? Can the task carry on and react to the error?
By default, if a step fails the task stops there: the following steps are never executed.
If you would rather it carried on, open that step in the editor and look for the Behavior section. There are two checkboxes:
Combining that with rules lets you build two paths in the same task: a step that only runs if error_message is not empty (the failure path) and another that only runs if it is empty (the normal path). That way a task can try something and, if it does not work out, try something else or let you know, instead of stopping silently.
Bear in mind that the checkbox does not tell one error from another: it makes the task carry on after any failure of that step. If you only want to react to a specific error, check its text in the rule of the following step.
If you would rather it carried on, open that step in the editor and look for the Behavior section. There are two checkboxes:
- Continue even if this step fails: the step fails, but the task carries on.
- Continue even if this step returns no data: the step finds nothing, but the task carries on.
Combining that with rules lets you build two paths in the same task: a step that only runs if error_message is not empty (the failure path) and another that only runs if it is empty (the normal path). That way a task can try something and, if it does not work out, try something else or let you know, instead of stopping silently.
Bear in mind that the checkbox does not tell one error from another: it makes the task carry on after any failure of that step. If you only want to react to a specific error, check its text in the rule of the following step.
What is the difference between pausing, resetting and activating a task?
A task has only two states: active or paused. The actions live in your task list, each task with its own buttons.
- Pause: the task stops attending its trigger but keeps all its internal state (where it was, counters, temporary data).
- Activate: it attends its trigger again and carries on where it left off.
- Reset: it goes back to being brand new — pointers, counters and temporary data are deleted. It does not delete the task, only its execution memory. This is what to use when a task "got stuck" and you want it to start from scratch.
How does data travel from one step to the next? And what if two steps output a variable with the same name?
Every step publishes its output variables and Botize keeps accumulating them: any step can use the variables of every previous step, not just the one right before it. You write them in double braces, for example {{title}}.
The detail that causes trouble: if two steps publish a variable with the same name, the later one overwrites the earlier one. It happens easily, because names like title, url or text are used by many applications.
The fix is renaming. Every step has a Customize tags option that lets you give a different name to the variables that step publishes. If step 2 outputs url and step 4 does too, rename step 2's to something like product_url and both will coexist without clashing.
The detail that causes trouble: if two steps publish a variable with the same name, the later one overwrites the earlier one. It happens easily, because names like title, url or text are used by many applications.
The fix is renaming. Every step has a Customize tags option that lets you give a different name to the variables that step publishes. If step 2 outputs url and step 4 does too, rename step 2's to something like product_url and both will coexist without clashing.
What kinds of trigger can a task have?
The trigger is what decides when the task runs, and it is always the first step. There are three kinds:
- Every so often: the task runs by itself at the frequency you choose.
- When something happens in an application: for example when an email arrives, when someone writes to your Telegram bot, or when something is published on a channel. The task sleeps until that service reports the event. It is the application's own trigger: there is nothing else to configure to make it instant.
- On request: the task waits for someone to call it from outside (a web address the data is sent to), or for you to run it by hand.
What is the difference between putting rules on a step and using the Filters step?
Both are conditions, but they do different things, and mixing them up is a classic source of surprises:
In both cases conditions are grouped: inside a group all of them must be met (AND), and it is enough for one group to be met (OR). That is how you build different paths in the same task: a step that only runs in one case and another that only runs in the opposite one.
- Rules inside a step (the Rules section you see when configuring it): if they are not met, that step is skipped and the task carries on with the following ones.
- The Filters step: if it is not met, the task dies there and nothing downstream runs.
In both cases conditions are grouped: inside a group all of them must be met (AND), and it is enough for one group to be met (OR). That is how you build different paths in the same task: a step that only runs in one case and another that only runs in the opposite one.
What happens to the variables of a step that was skipped by its rules?
A step that is skipped publishes nothing. And a variable nobody published does not behave as "missing": it reads as empty.
That has a surprising consequence: a rule like "this thing is empty" is also met on every path where the step that produces that variable never even ran.
The typical case. A task looks up a product and, if it does not find it, looks for alternatives. The last step —the one that says nothing was found— carries the rule "alternative is empty". When the product IS found, the alternatives step is skipped, "alternative" is never published, it reads as empty… and that last step answers anyway. The user gets the product and, right behind it, a message saying nothing was found.
How to avoid it. Every path also carries the condition that identifies itself, not just the absence of the others. In the example, the step that reports nothing was found must ask for two things at once: that the product lookup failed and that there is no alternative. Remember that two rules inside the same group must both be met (AND) and that across different groups one is enough (OR).
Before calling a multi-path task done, walk the paths one by one and check that exactly one step answers each situation. Two steps answering the same case is a bug; none answering it is one too.
That has a surprising consequence: a rule like "this thing is empty" is also met on every path where the step that produces that variable never even ran.
The typical case. A task looks up a product and, if it does not find it, looks for alternatives. The last step —the one that says nothing was found— carries the rule "alternative is empty". When the product IS found, the alternatives step is skipped, "alternative" is never published, it reads as empty… and that last step answers anyway. The user gets the product and, right behind it, a message saying nothing was found.
How to avoid it. Every path also carries the condition that identifies itself, not just the absence of the others. In the example, the step that reports nothing was found must ask for two things at once: that the product lookup failed and that there is no alternative. Remember that two rules inside the same group must both be met (AND) and that across different groups one is enough (OR).
Before calling a multi-path task done, walk the paths one by one and check that exactly one step answers each situation. Two steps answering the same case is a bug; none answering it is one too.
Which conditions can I use in a task, and where does each one work?
A condition can be placed in four different places of a task, and they do not all understand the same set. This table says, for each condition, where it works. It is generated from the engine, so it does not go stale.
If you use a condition somewhere it is not available, the task fails when it runs. Worth checking the column first.
| Condition | Technical name | Takes a value | Rule on a step | «Filters» step | «Filter a list» step | Branch of a flow |
|---|---|---|---|---|---|---|
| Change | change | — | yes | yes | yes | — |
| must contains all this words | contains_all | yes | yes | yes | yes | yes |
| must contain at least one of this words | contains_certain | yes | yes | yes | yes | yes |
| must contain at least one of this words (case sensitive) | contains_certain_cs | yes | yes | yes | yes | yes |
| Month day must be | containsdaymonths | — | yes | yes | yes | — |
| week day must be | containsdays | — | yes | yes | yes | — |
| hour must be | containshours | — | yes | yes | yes | — |
| Month must be | containsmonths | — | yes | yes | yes | — |
| Decreases | decreases | — | yes | yes | yes | — |
| Does not exist | empty | — | yes | yes | yes | yes |
| Equals | equal | yes | yes | yes | yes | yes |
| date must be | equal_date | yes | yes | yes | yes | — |
| Exists | exists | — | yes | yes | yes | yes |
| False | false | — | yes | yes | yes | yes |
| Changes from False to True | false_to_true | — | — | — | yes | — |
| ↥ Greater than | greaterthan | yes | yes | yes | yes | yes |
| Grows | grows | — | yes | yes | yes | — |
| Must be in this list | in_array | yes | yes | yes | — | yes |
| Has no value | is_null | — | yes | yes | — | yes |
| the number of characters is greater than | len_greaterthan | yes | yes | yes | yes | yes |
| the number of characters is less than | len_lessthan | yes | yes | yes | yes | yes |
| ↧ Less than | lessthan | yes | yes | yes | yes | yes |
| once after a day | newday | — | yes | yes | yes | — |
| once after a day and a certain time | newdaytime | yes | yes | yes | yes | — |
| Does not exists | non_existent | — | yes | yes | yes | yes |
| Not equal | not_equal | yes | yes | yes | yes | yes |
| Must not be in this list | not_in_array | yes | yes | yes | — | yes |
| not seen in the last day | not_seen_1d | — | — | — | yes | — |
| not seen in the last hour | not_seen_1h | — | — | — | yes | — |
| not seen in the last 30 days | not_seen_30d | — | — | — | yes | — |
| not seen in the last 7 days | not_seen_7d | — | — | — | yes | — |
| must not start with any of these words | not_starts_with | yes | yes | — | yes | yes |
| must not contain any of this words | notcontains | yes | yes | yes | yes | yes |
| Exists | notempty | — | yes | yes | yes | yes |
| must start with at least one of these words | starts_with_certain | yes | yes | — | yes | yes |
| since that time has passed less than | timeafterlessthan | yes | yes | yes | yes | — |
| since that time has passed more than | timeaftermorethan | yes | yes | yes | yes | — |
| time must occur after | timeafterthan | — | yes | yes | yes | — |
| time must occur before | timebeforethan | — | yes | yes | yes | — |
| The total number of items is | total_items_equal | yes | yes | yes | — | — |
| The total number of items is greater than | total_items_greater_than | yes | yes | yes | — | — |
| The total number of items is less than | total_items_less_than | yes | yes | yes | — | — |
| True | true | — | yes | yes | yes | yes |
| Changes from True to False | true_to_false | — | — | — | yes | — |
| Unchanged | unchanged | — | yes | yes | yes | — |
| the number of words is greater than | words_greaterthan | yes | yes | yes | — | — |
| the number of words is less than | words_lessthan | yes | yes | yes | — | — |
«Rule on a step» is the Rules section of any step. «Filters» and «Filter a list» are the two methods of the Filters step. «Branch of a flow» is each path of a task drawn with branches: only conditions that depend solely on the incoming data work there, not those that compare against previous runs.