Types of modules

In , a module is a building block you use to create a . Think of it as bricks that you put together to automate your processes.

Each module performs a particular action, such as retrieving data from a service, creating or updating a record, downloading a file, or searching for specific data based on certain conditions. For example, your can have three modules: one module watches for new customer data in a CRM, the second module converts the data into another format, and the last module sends that information to a different service.

You can find all available modules in the app list when selecting a specific app in the editor.

Understanding each module type helps you navigate more easily, build advanced , and optimize operations while reducing costs.

In this article, you'll discover the different types of modules in and how to use them in your . If you're an advanced user, be sure to check out the section on tips and examples for more in-depth insights.

You can categorize modules into four groups depending on what they do with data in :

A trigger is a module used to track changes in a service and pulls it to so you can use the data in your . A trigger only shows new data from your service account. Each time a processes trigger data, it's data that hasn't been processed before in that .

For example, a trigger might detect when a new record is created, or an old record is deleted.

You can add a trigger only once in the as the first module. This ensures that the trigger initiates the by detecting the relevant changes and pulling in the data for further processing.

There are two types of triggers in :

A polling trigger checks if there are any changes in your service account since the previous run according to the scenario schedule. A polling trigger makes a request to the service. If there are changes, you see them in the module’s output as bundles. If there are no changes, you see no bundles.

You can recognize a polling trigger by its name: it usually starts with Watch: Watch a record, Watch a row, etc. A polling trigger never has an instant tag attached to it.

You can select a starting point when a module starts tracking changes in the service. See more information in the Advanced tips and examples section.

An instant trigger works in a different way: the service notifies whenever a change happens. Basically, an instant trigger is a webhook - a link that the service uses to send data to whenever changes occur. When you add an instant trigger, asks you to create a webhook. Some services may require to create a connection before you can create a webhook.

It's like buying plane tickets. A polling trigger is when you visit the airline's website yourself to check for discounts. An instant trigger is like getting a notification from the website when discounts are available.

You can recognize an instant trigger by a lightning icon and an instant tag:

A Search module helps you to get specific data from a service such as records, profiles, or other objects.

Search modules are flexible. You can add as many as you need and place them anywhere within your .

There are two types of search modules in :

An Action module processes the data retrieved from a service. It’s one of the most commonly used modules in .

You can include as many as you need and position them anywhere in your .

There are the following types of actions in :

Some actions are specific to the service, such as pin, save, or download.

A Universal module allows you to make a custom API call to a service when doesn't provide a pre-built module for an API endpoint you need. This module, usually called the Make an API Call module, is available for most services. You may need to refer to the service API documentation to see a full list of available API endpoints.

You can add as many Universal modules as needed and place them anywhere in your .

Modules can be split into two groups based on whether they need to connect to a service or use a third-party API. There are two types:

When adding modules of an app, you need to create a connection to start working with them. Each module serves a specific action. For example, to get data, create a record, or delete a profile in your service account. You can associate a certain app module with a specific service API endpoint.

LinkedIn, Google Sheets, HubSpot CRM, Trello and many more are apps in . When you add a module, you see the Create a connection or Create a webhook buttons. In the Connections section, you can learn more about connections in .

With tools, you don't need to set up a connection nor use a third-party API. Instead, you enter your data or customize module settings, and the module is ready to work. Examples include Iterator, Aggregator, Data store, Compose a string, Set variable, and many more.

These modules are ready to go as soon as you add them. However, some tools might require some setup before you can use them. For example, Data store might ask you to create a data store within .

In this section, you can find advanced tips and practical examples for using modules in .

While using modules, you might run into limits that could cause errors in your .

Most Searches can only process up to 3,200 objects or 5MB of data per run. You only see the first 3,200 objects searched or as many as fit within the 5MB limit, even if there are more. Some modules only have a data size limit: each module can receive or process up to 5MB of data per run.

Keep in mind that the service's API limits may apply. For example, if the API allows only 1,000 objects, that’s all you will receive no matter which type of modules you use. You can refer to the service API documentation to learn more about its limits.

Here are two best practices to avoid errors and make sure your runs smoothly:

If you use the Limit field, it's essential to set the right limit for the data being returned per one run. For example, with a polling trigger, you need to find a balance:

We recommend setting the limit according to the number of new objects you plan to get for each run.

Modules tagged as ACID support rollback. will undo all the actions an ACID module takes if an error occurred in subsequent modules.

Imagine your ACID module receives two bundles. The next module processes the first one but encounters an error with the second one. In this case, rolls back the ACID module as if nothing was received. On the next run, the ACID module gets the same two bundles again. The next module being non-ACID will try to process both bundles once again.

You can recognize the ACID module by the ACID tag:

Unlike Search modules that provide information about all objects or objects that match module filters, a Get module helps to receive information about one specified object. You should specify an object ID to get information about it.

For data, this means Search or List modules usually return several bundles because there are multiple objects to retrieve. Get modules, however, always return a single object, which means only one bundle.

With an Update module, you can perform three actions:

While we recommend starting a Make with a Watch module, you can also begin with a Search module or Action module, depending on your goal. For example, if you need specific data, a Search or List module can act as a polling trigger starting a Make according to the Make schedule.

You can decide where to start to track changes made in the service. To do it, right-click the module and then click Choose where to start.

Typically, you have the following options:

Settings may vary depending on the app.