Action Assemblies

action input all action assemblies begin with an action module that defines input data fields for the action to process static input data fields can be typed into the module and configured manually generally this is only done when the action has a relatively small number of input fields dynamic data fields can be loaded from a nested subassembly as an example of when dynamic fields must be loaded, consider a spreadsheet action to write a new row the action doesn't know which columns are available until the sheet is inspected via the api and its columns are determined rather than keying in and configuring a lot of static data fields by hand, you can create a subassembly and use the data streams – create from text module to configure the fields from static xml data, which can be easier to create the outputs from the action module are then typically formatted for sending to the api the json builder and xml builder modules can be helpful for formatting simple api payloads complicated json/xml formatting usually requires custom coding via the extension – server side script module once data is formatted in the manner needed, the api is invoked via the http or oauth transaction modules, or one of their variants action error handling after invoking an api call, the action should check for any error conditions and raise a fatal error if the api call was unsuccessful actions must catch and throw all error conditions in order for the transaction to be flagged as an error in the automation’s history and for alert processing to be performed the proper way to do error checking in an action is to test for the absence of a successful result from an api call for example, if you are adding a new contact to a crm then check the api’s response to ensure that the new contact id is returned or test for the http status code the api uses to indicate success some actions need to indicate to the system that the trigger data row should be skipped rather than retried for example, an action that checks for existing duplicate data needs to skip the trigger data row if a duplicate exists the action skip data row module can be used within a conditional module for this action output actions can emit output data fields via the action output module the output data fields can be used as inputs to subsequent actions within automations similar to the action module, output fields can either be statically typed into the module or they can be determined dynamically for dynamic output fields, the action extract output data fields module can be used to automatically parse output fields from a data stream (typically the api's response) if an action output module emits dynamic fields, the action assembly is executed in the automation editor when configuring the automation in order to determine the mappable fields the action must not perform any api calls that modify data! use the utility when in module and conditional modules to control processing that occurs when configuring the action in the automation editor vs its behavior when running in an automation see the zoom "get meeting" action for an example of this, uuid = 073aac7ff0d2447c87ed298aa4032213 for actions that only emit dynamic output fields, in most cases you will want to define default output fields in case the action logic is unable to fetch an api record at the time the action is configured in the automation editor review the help info about default output by mousing over the default output field in the module action throttle actions can be configured with a throttle to enforce api rate limits an action's thottle is defined when it is saved a scope for the throttle can be configured if empty, the throttle is scoped to this individual action and app connection if not empty, other actions in the same app having the same app connection and the same entered scope will share the throttle an example of using a scope is the hubspot api, which has a different rate limit for their search api multiple 'find' actions can all use the search api and share the same throttle scope to remain under the search api's rate limit action throttles are intended to be used for exception cases that differ from an api's typical rate limits some api providers will enforce more stringent rate limits on certain endpoints for more flexible rate limit rules, including across multiple accounts, see the rate limits docid\ qwegt6 mzy8mupcs62ar9 section that covers the usage of a rate limiter action that can be used in automations action throttles are enforced regardless of other automation level rate limits applied