Boost.space IntegratorPart of the Boost.space system, where you can create your connections and automate your processes. distinguishes five types of modules: Actions, Searches, TriggersThe 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., Aggregators and Iterators. The two latter ones are intended for advanced scenariosA specific connection between applications in which data can be transferred. Two types of scenarios: active/inactive..
Actions are the most common module type.
-
A typical action moduleYou can create, read, update, or delete data with an action module. Action modules are the most common type of module and can be at the beginning, middle, or end of a scenario. There is no limit to the number of action modules in your scenario. returns just a single 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. which is then passed on to the next module for processing.
-
Action modules can be placed at the beginning, middle, or end of a scenarioA specific connection between applications in which data can be transferred. Two types of scenarios: active/inactive..
-
Scenarios can contain an unlimited number of action modules.
-
Dropbox > Upload a file sends a file to a selected Dropbox folder and returns its identifier.
-
Image > Resize receives an image, resizes it to specified dimensions, and passes the resized image on to the next action.
-
Google Analytics > Create a report gets information about web traffic and passes it on for further processing.
The Action type has four sub-types: Create, Read, Update and Delete. The Update sub-type enables the following three 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.:
-
Erase the content of a field. This 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. takes place when the content of the field is evaluated to
erase
keyword (not to be confused with empty): -
Leave the content of a field unchanged. This operation takes place when the field is left empty or the content of the field is evaluated to empty (represented via null in JSON):
-
Replace the content of a field. This operation takes place in all other cases than those two described above.
Note | |
---|---|
If you do not see the |
The reason, why it has been decided that empty will result in no change of the field content is that if there is a need to act differently and erase the field instead then it is easily achievable with the following formula:
whereas leaving the content of the field unchanged when the field’s content is evaluated to empty is currently not possible.
-
A typical search module returns zero, one, or more bundles which are then passed on to the next module for processing.
-
Search modules can be placed at the beginning, middle, or end of a scenario.
-
Scenarios can contain an unlimited number of search modules.
-
Monday > List pulses in all boards returns all account’s pulses.
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 generate bundles when there has been a change in a given service. The change can be a creation of a new record(s), deletion of a record(s), update of a record(s), etc. Boost.space Integrator distinguishes between two types of triggers: Polling triggers and Instant triggers.
-
Every trigger can return zero, one, or more bundles which are then passed on to the next module for processing.
-
Triggers can be placed only at the beginning of a scenario.
-
Each scenario can contain only one trigger.
Polling triggers are designed to regularly poll a given service whether there has been a change since their previous run. So you will typically schedule a scenario containing a polling trigger module to run periodically by selecting for example At regular intervals option from the Schedule setting panel. If there is a change the trigger will return bundles containing information about the change. If there is no change the trigger will output no bundles.
Polling triggers allow you to select the first bundle they should output via the epoch panel. The panel is displayed automatically after you save a trigger or when you make a substantial change in the trigger settings. You can also display the panel by right-clicking the module and choosing “Choose where to start” from the context menu.
Note | |
---|---|
Settings made in the epoch panel affect only the first execution of the module. Once the module is executed, it will remember the last outputted bundle and the settings made via epoch panel will be voided. |
-
Dropbox > Watch files returns files that were newly added since the last time the scenario was run.
-
Twitter > Watch Tweets returns new Tweets posted by the user since the last time the scenario was run.
-
Tumblr > Watch posts returns new posts added to a selected blog since the last time the scenario was run.
Instant triggers enable the service to notify Boost.space Integrator about the change immediately. You will typically wish to schedule a scenario containing an instant trigger to run immediately by selecting the Immediately option from the Schedule setting panel. See also Webhooks for further details on how the incoming data are handled.
-
Paypal > New notification returns new payment notifications.
Aggregators are modules that accumulate multiple bundles into one single bundle.
-
Every 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. returns only one bundle which is then passed on to the next module for further processing.
-
Aggregators can be placed only in the middle of a scenario.
-
Scenarios can contain an unlimited number of aggregators.
-
Archive > Create an archive compresses received files into a zip archive.
-
CSV > Aggregate to CSV merges multiple strings from a CSV file into a single row.
-
Tools > Text aggregatorAn aggregator is a type of module that allows you to merge multiple bundles into one single bundle. Aggregators are useful in making data readable for certain modules or generating meaningful output. Boost.space Integrator offers:
Array aggregator
Numerical aggregator
Table aggregator
Text aggregator
combines several strings together into one single string.
Iterators are modules that split arrays into multiple, separate bundles.
-
Every 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. returns one or more bundles which are then passed on to the next module for processing.
-
Iterators can be placed only in the middle of a scenario.
-
Scenarios can contain an unlimited number of iterators.
-
Email > Retrieve attachments breaks an 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,... of attachments into separate bundles.