Operations

each time a module performs an action, it uses an operation for example, adding a row to your google sheet or getting data from your gmail account, each uses one operation understanding your operation usage is important because make charges based on the total number of operations performed by the modules in your scenario more modules and bundles processed in a scenario result in a higher number of operations if you exceed your monthly operation limit, your scenarios will be paused until the next usage reset to resume your scenario immediately, you can purchase additional operations or you can enable the extra operations auto purchasing to prevent your scenarios from pausing in the future you can learn more about the available options below in addition to the number of operations, each plan gives you a certain amount of data that your scenarios can process during the usage period you can find more information about your usage allowance here https //www make com/en/pricing how modules use operations every time a module in a scenario performs an action, it uses one operation if a module outputs multiple bundles of information (like a list module returning multiple records), it makes the following module run once for each bundle, processing each record separately the total number of used operations for a module equals the number of performed actions all the types of modules can use from one to many operations, depending on their place and function in the scenario trigger modules always use one operation regardless of whether they receive any data or not search modules use one operation to run, but can output multiple bundles for example, the google sheets search row module will run once and use one operation, but it can return information about multiple rows after one run each row is a separate bundle of data action modules ( add , update , delete , etc ) use as many operations as many runs they need to make to process all the input data if you have 10 rows returned by the google sheets search row module the next delete rows module will run 10 times to delete all the 10 rows and will use 10 operations aggregator modules take multiple bundles and combine them into one the aggregator uses one operation for each aggregation if the aggregator creates one array from your google sheets records, it will use just one operation iterator modules are opposite to the aggregator modules iterators take one array bundle and split it into multiple bundles as an output, so they use one operation for the entire array, but modules after them will receive more than one input there are a few exceptions of modules when make does not use the operations error handlers (rollback, break, resume, commit, ignore) router modules and filtering example add top tracks from a selected artist to your liked songs on spotify in this senario, make gets the list of the top 10 songs of an artist you select, and adds it to the list of the songs you liked once the execution of a scenario is completed, make displays the number of operations performed by each module in the little white circle above the module in this example, the first spotify module returned 10 songs and performed 1 operation while getting the information each song is returned as a bundle of information, so the next module has to work with 10 bundles the second spotify module had to add each of the 10 songs to the playlist, requiring it to perform this action 10 times as a result, the module processed 10 bundles and used 10 operations the run of this scenario required 11 operations in total in this example, spotify limits each artist to 10 top songs however, you can control the number of operations your scenario uses by restricting the number of results for search and list action modules for example, you can create a scenario that adds new songs from an artist to your playlist but limit the list module to return only 5 songs this way, only 5 new songs are added per run instead of an entire album of 30 songs, saving operations additionally, you can use filters to process only specific bundles returned by modules this ensures that only the bundles passing the filter are processed, consuming fewer operations checking the total operations count for a scenario in the example above you can see how to count operations for a scenario during one run but it is also important to know how many operations your scenario is using in total scheduling your scenario will make it consume operations every time it runs for example, if your spotify scenario is scheduled to run every hour, that would equal to 264 operations a day (11x24) if you schedule it to run every 5 minutes, it will consume 3168 operations per day (11x24x12) that's why it's important to schedule your scenario carefully you can reduce the number of used operations by scheduling some scenario to run less frequently every scenario run uses at least one operation because the trigger module needs to check for updates even when no new data is retrieved, these check runs still add to your total operation count, as the trigger uses an operation each time it checks according to the schedule you can view all the check runs from the history tab in your scenario if you don’t see them, ensure that the hide check runs toggle is off you can also check how many operations your scenario has consumed in total without calculating anything you can easily find this information in the list of scenarios or the scenario history from the list of scenarios when you open a list of scenarios, you can see how many operations each scenario has consumed under its name if you hover over the number you can see the date when the count started (the beginning of the usage period) for yearly subscriptions, the label displays the reset date, but the data represents an aggregated usage within the last 60 days from the scenario history to open the scenario execution history, click on the scenario from the list of scenarios under history on the right, you can see the number of operations consumed for each scenario run similarly, you can switch to the history tab and see the number of consumed operations for each run there in a table format when a regular execution ends with a warning or error, an incomplete executions is created any attempts to fix it are tracked in the incomplete executions tab, with each attempt consuming operations these operations add to the total used by the scenario and are included in the operations usage displayed in the list of scenarios, even though they aren't visible in the history tab you can view the operations used to resolve an incomplete execution in the incomplete execution details note that, by default, the storage of incomplete executions is disabled, but you can enable it individually for each scenario checking the total operations count for the organization or team while it is important to know how many operations each scenario consumes, it is also important to know how many operations your organization and each team within the organization use this can be easily checked from both organization and team dashboards to open the dashboard, click organization or team in the left side navigation from the organization dashboards it is also possible to see the limits you have according to your plan, how many operations were used during the current period, and to check the options of purchasing additional operations if needed if you are running out of operations when you run out of operations, your scenario will pause until additional operations are added or the next billing cycle begins incoming webhooks will be queued based on your available webhook storage and processed once your scenarios resume with the new operations additionally, scenarios that poll for data will search for available records since the last successful run if you are on the enterprise plan, your scenarios will continue to run thanks to the operations overage protection https //www make com/en/help/general/pricing parameters during this time, your account manager will contact you to resolve the issue and prevent any interruptions we'll notify you when you're approaching 75%, 90%, and 100% of your purchased operations this way, you can ensure you have enough operations to meet your needs or take action to prevent your scenarios from pausing here’s what you can do if you run out of operations before the next billing cycle upgrade your subscription https //www make com/en/pricing before the end of the cycle purchase extra operations auto purchasing in bundles of 1,000 or 10,000 operations at the fixed price defined in your subscription extra operations work the same as pre purchased operations and expire after the current billing period (monthly or yearly) enable the auto purchasing once you use all 10,000 extra operations, make auto purchases 10,000 operations again make limits auto purchasing to the number of operations in your subscription for example, if your plan has 80,000 operations, auto purchases can happen up to 8 times make charges you for the 10,000 operations based on your plan, plus a 30% surcharge you can learn more about this option extra operations auto purchasing