website logo
⌘K
Explore our documentation
Contact APIANT support
What is APIANT?
Automation Editor
Key Concepts
Account Management
Managing Automations
App Connections
Building Automations
Alert Mappings
Troubleshooting
CRMConnect: Mindbody → HubSpot
CRMConnect: DonorPerfect → HubSpot
CRMConnect: DonorPerfect → ActiveCampaign
MailConnect: DonorPerfect → Mailchimp
ShopConnect
ShopConnect Settings
Sync Products
Manually sync Mindbody services/pricing options to Shopify
How to tag products in Shopify to prevent sync during sales sent to Mindbody
Retrying orders from Shopify → Mindbody
Manually pushing Mindbody orders to Shopify
Mindbody Pricing Discontinuation: Integration with Shopify
Guide to manually syncing Mindbody Packages with Shopify Products
Features that are not supported in ShopConnect
Automation Alert Reports
Linked Accounts
ZoomConnect
New features in version 4
Settings
General
Email & SMS
BOTs
MINDBODY
Zoom
ZoomConnect Mindbody Appointments - Setup and requirements
Troubleshooting
Assembly Editor
Key Concepts
Account Management
API Key Management
Managing Content
Building Assemblies
API Integrations
Other Assembly Types
Keyvalue Storage
Assembly development cycle
APIANT for Integrators
Help Forum
Automation Templates
Development Server
Module IDE
Shared App Connections
Tenants and Linked Accounts
APIANT Inline
Supported functionality
Embed Inline
Sandbox
Docs powered by
Archbee
Assembly Editor
API Integrations

Action Assemblies

8min

Action Input

All Action assemblies begin with an Action module that defines input data fields for the action to process:

Document image


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:

Document image


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:

Document image


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):

Document image


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:

Document image




Updated 03 Mar 2023
Did this page help you?
PREVIOUS
Trigger/Action Commonality
NEXT
Trigger Assemblies
Docs powered by
Archbee
TABLE OF CONTENTS
Action Input
Action Error Handling
Action Output
Docs powered by
Archbee