Understanding Operations in Integration Scenarios: Maximizing Efficiency with Boost.space

OperationsOperations are tasks in integration scenarios, similar to "operations" in Make.com. Each action, like reading or updating a record, counts as one operation. They’re essential for data syncing between apps and reset monthly. Going over the limit pauses syncing until you add more or upgrade your plan. are related to our integration scenariosA specific connection between applications in which data can be transferred. Two types of scenarios: active/inactive.. Whenever any task is performed by your integration, it counts as an operationOperations are tasks in integration scenarios, similar to "operations" in Make.com. Each action, like reading or updating a record, counts as one operation. They’re essential for data syncing between apps and reset monthly. Going over the limit pauses syncing until you add more or upgrade your plan.. It is very similar to Zaps in Zapier or OperationsOperations are tasks in integration scenarios, similar to "operations" in Make.com. Each action, like reading or updating a record, counts as one operation. They’re essential for data syncing between apps and reset monthly. Going over the limit pauses syncing until you add more or upgrade your plan. in Make. If you run out of your operations, your data synchronization scenarios will stop. Operations are refreshed each month or you can also upgrade your Tier. Typically it takes at least between 2-4 operations to sync one record to or out of Boost.space (this depends on the third-party tool and the complexity of your integration scenarios). During the first sync, usually, all records are synchronized, and then only changes get updated across your tools, optimizing the number of operations consumed. Please keep in mind that this depends/varies on the possibilities of your source or destination third-party tools (type of scenarios, modules and other things).

For example, when your scenario reads a record from Pipedrive, or writes one row into a Google sheet each counts as one operation.

Depending on the complexity of the process you’re automating, your scenarioA specific connection between applications in which data can be transferred. Two types of scenarios: active/inactive. can perform anywhere from two operations to thousands of operations in a single run.

Don’t worry about using up all your operations before the end of the month or year. You can always buy extra operations or upgrade to a higher tier plan.

How Modules utilize Operations

Different modules consume varying numbers of operations, depending on their role in the scenario:

• TriggerThe initial event that starts a scenario. It can be an action, a scheduled time, or a custom event, and is essential to define at the beginning of each scenario. modules always use one operation, whether they receive data or not.
• Search modules require one operation to run, but they can output several bundles. For example, the Google Sheets Search Row module uses one operation to retrieve multiple rows, with each row considered as a separate bundleA bundle is a chunk of data and the basic unit for use with modules. A bundle consists of items, similar to how a bag may contain separate, individual items.  .
• Action modules (Add, Update, Delete, etc.) use as many operations as needed to process all input data. For example, if 20 rows are found by a Search module, a Delete Rows module will run 20 times, using 20 operations to delete each row.
• AggregatorYou can use a table aggregator to create a table from multiple bundles. The table aggregator merges values based on your specified column and row parameters and outputs into a single bundle. One possible use is compiling blog posts or emails into a single email summary. modules merge multiple bundles into one. Each aggregation uses one operation. So, if you combine Google Sheets records into a single array, it will only consume one operation.
• IteratorWhen creating a scenario, use an iterator to divide one bundle into smaller separate bundles. Subsequent modules then process the bundles separately. One common use is when automatically uploading email attachments to a cloud drive. You can find iterators under the Flow control of the tools section. modules work the opposite way. They split one arrayWithin a bundle, data items of the same type are sometimes in an array. You can find an array by looking at the details of a bundle. Depending on the details of your scenario, you can map other modules to a specific item in an array or use iterators and aggregators to manipulate your data into other formats. When mapping,... bundle into multiple smaller bundles. Although they use just one operation for the array, the modules that follow will process more than one input bundle.

There are a few exceptions of modules when Boost.space doesn’t count the operations or counts them differently:

• Error handler modules (Rollback, Break, Resume, Commit, Ignore) – no operations counted
• RouterA router allows you to add new routes to a scenario so you can branch your flow into several routes and process the data within each route differently. – no operations counted
• Sleep module – consumes operations, but doesn’t consume data

How to check the number of Operations in a Scenario

When you schedule a scenario, it will use operations every time it runs, so it’s important to schedule wisely. To reduce the number of operations, consider running some scenarios less frequently. Each run will always consume at least one operation since the trigger module checks for the data, even if nothing is found. These checks still count toward your total operation usage. You can review them in the History tab of your scenario, but make sure the “Hide check runs” option is turned off so you can see all the activity.

1. Directly in the ScenarioThe simplest way to see how many operations a scenario consumes during a run is by opening the specific module in the scenario. A table will appear, showing the operation count.
2. From the Scenario ListIn the scenario list, you can quickly check how many operations each scenario has used. The total is displayed beneath the scenario’s name. If you hover over the number, you’ll also see when the usage period started.
3. From the Scenario’s History To check the operation count for each run, open the scenario from the list and go to the History section on the right. Here, you’ll see the number of operations consumed per run in a table format.

If a scenario run ends with a warning or error, it creates an incomplete executionSometimes Boost.space Integrator cannot successfully finalize a scenario execution due to an error. Boost.space Integrator stores incomplete executions in a folder named Incomplete Executions. Each stored incomplete execution can be resolved either manually or automatically.. Attempts to fix this issue also consume operations, which are tracked in the incomplete executionsSometimes Boost.space Integrator cannot successfully finalize a scenario execution due to an error. Boost.space Integrator stores incomplete executions in a folder named Incomplete Executions. Each stored incomplete execution can be resolved either manually or automatically. tab. These operations contribute to the overall usage count, although they don’t appear in the History tab. However, you can view them in the incomplete execution details. By default, incomplete execution storage is turned off, but you can enable it for specific scenarios.

How to check the number Operations for Your Organization

If you want to see how many operations your Organization is using, you can easily find this information on the respective dashboards. To access the dashboard, click on Organization in the left-hand menu.

On the Organization dashboard, you can also see your plan’s operation limits and how many have been used during the current period.

If you have any additional questions, please do not hesitate to reach out to us at [email protected].