In this article, we explain the most important elements you should know for using our automation platform and creating scenario.

Scenario: A scenario is a visualized workflow that is initiated by a trigger and in which data is passed and/or modified by a sequence of modules. The workflow can include only actions within doo or include actions from other software providers (integration). A scenario can be executed once, have a scheduled recurrence (for example, daily), or be triggered on demand by the occurrence of a specific event (for example, a new booking has been created). When creating a scenario, you can drag and drop all the elements you need.

Module: Modules are the main elements within a scenario and can retrieve, read, create, modify or delete data. There are 5 types of modules: Actions, Searches, Triggers, Aggregators and Iterators.

Action: Actions are the most common modules. They can read, create, modify or delete data and can be placed anywhere within a scenario (beginning, middle or end). They usually return a single bundle of data, which is then passed to the next module within the scenario. There can be any number of actions in a scenario.

Search: Searches are modules that start a search and output the result. The result can contain zero, one or more bundles. The bundles can then be passed on to the next module (an iterator may be needed). Searches can be placed anywhere within a scenario. There can be an unlimited number of searches in a scenario.

Bundle: A bundle is a data bundle, i.e. one or more key-value pairs.

Triggers: Triggers are modules that trigger a scenario. Each scenario must have exactly one trigger, which is placed at the beginning. A trigger creates a bundle only if there has been a change in the respective service or application. Each trigger can return zero, one or more bundles. We distinguish between polling and instant triggers. Polling triggers make a request to a service and return a result if there has been a change since the last run of the scenario; therefore, they are usually set as repeating modules with regular intervals (for example, hourly or daily). Instant triggers, on the other hand, send a notification to Make as soon as a change occurs in the respective service. Technically, instant triggers are based on webhooks that the service sends to Make.

Aggregator: Aggregators are advanced modules that combine multiple bundles into a single bundle that is then passed to the next module in the scenario. They can only be in the middle of a scenario and there can be an unlimited number of aggregators.

Iterator: Iterators are advanced modules that split arrays into multiple, separate bundles. An array is a data bundle that contains multiple objects with the same structure. An iterator can return one or more bundles, which are then passed to the next module in sequence. They can only be in the middle of a scenario and there can be an unlimited number of iterators. An example of using an iterator is to split a search result with multiple matches into the individual values and pass each of them on as a separate bundle.

Filters: Filters control the execution of workflows by using conditional statements. If the data meets the conditions specified in the filter, it is passed on to the next module. Otherwise, the scenario ends at this point unless another procedure is defined.

Router: Routers divide a workflow into different branches. They are mostly used in combination with filters to process certain data sets differently via the different routes.
A data bundle passes through all routes that either do not contain a filter or where the condition of the filter is met. Each route after a router is processed sequentially, not simultaneously, and the routes are processed in the order in which they were created. The order can be changed by unlinking all routes and relinking them in the order in which they should be processed. The fallback route is used only when a data bundle does not pass through any other route. It is like the ELSE condition in an IF statement.

Error Handling: This element allows you to define the behavior in case of an error. Error handling can be recognized within a scenario by the fact that the connection circles between the modules are transparent and not colored. With the help of the error handling you define whether the execution of the scenario, when a problem occurs, should be

• continued
  • “Resume” → a replacement output is specified and the scenario is marked as a success
  • “Ignore” → the problem is ignored and the scenario is marked as a success
  • “Break” → the scenario is marked as a warning or
• stopped
  • “Rollback” → stops the scenario and marks it as an error
  • “Commit” → stops the scenario and marks it as a success.

Data store: Data stores are comparable to a simple database. A data store allows you to store data from a scenario or transfer data between different scenarios or within a scenario. Using the modules of the Data Store app, you can add, replace, update, retrieve, delete, search, or count records to your data store. You can view and manage your data stores and the data they contain at any time via the “Data Store” item in the main menu bar on the left.

Further help

Detailed explanations of the individual modules, error messages and tools, instructions for scenario creation, and a glossary of all important automation platform terms can be found in the help center of Make, on which our automation platform is based.

In addition, there is an Academy where you can watch video tutorials to get started with the platform as well as for many special use cases.