Key Concepts
Automation
An automation is a workflow that performs actions whenever its trigger criteria is met. Automations have one or more triggers and one or more actions. Actions can conditionally execute depending on optional conditional logic branches. Actions can iterate through array data via optional loops.
Automation Editor
The automation editor is used to build automations. Automations can be arbitrarily complex, in that they can invoke subroutines which may be nested.
App
Triggers and actions are bundled into apps that are then selected in the automation editor.
The term "app" is used loosely in APIANT. Most often it is a specific web service or application, like the Hubspot CRM. Other times, apps are system-provided bundles of functionality, like various data transforms.
Apps are integrated with the low-code Assembly Editor.
Trigger
A trigger is generally what causes an automation to process data. Triggers generally emit new or modified data rows that are to be processed by the automation's actions.
For example, a CRM polling trigger "new or updated contact" will emit new or modified contacts since the last time the trigger was executed.
There are different varieties of triggers:
Instant Webhook Triggers
Instant triggers fire whenever another system pushes data to the APIANT system via webhooks. Instant triggers have "(instant)" appended at the end of their names.
For example, a CRM "new or updated contact (instant)" trigger will fire every time a contact is added or modified in the CRM system. The CRM system will send a webhook to the APIANT system containing information about the contact that was added or modified. The automation will then be immediately queued for execution to process that contact.
Polling Triggers
Polling triggers are periodically executed by the system on a defined schedule, generally every 15 minutes. Upon each polling cycle, the system executes the trigger. The trigger then fetches data and compares it against previously processed data identifiers stored in APIANT's database. Depending on the type of trigger, new items and/or modified items are then emitted as determined by comparing what is in APIANT's database.
Date Time Triggers
Date Time triggers provide another way to control the scheduling of the automation's polling trigger(s).
A Date Time trigger can be combined with one or more other polling triggers:
The Date Time app provides various types of scheduling options:
Two-way Sync Triggers
Two-way sync triggers provide functionality to bidirectionally sync data between two systems. They are paired with two-way sync actions.
For example, this is a minimal automation to two-way sync client records:
Triggers are built with the low-code Assembly Editor.
Action
Actions put the work into workflows. They are what will free someone's time from mundane everyday tasks and generally save time and money.
Actions are built with the low-code Assembly Editor.
Subroutine
A subroutine is a type of automation that can be called by one or more other automations. A subroutine has defined input fields and defined output fields. A subroutine may call other subroutines.
Subroutines serve two main purposes.
The first is to provide a mechanism for building re-usable logic, such that a single subroutine can be re-used by multiple other automations.
The second is to provide a way to build very large and complex workflows. The automation editor limits a single automation to have no more than 150 actions. This limit is imposed due to browser and client machine limitations that affect the ability to render large diagrams with adequate performance.
Automation History
Every time an automation is executed, the APIANT system keeps detailed history information about the successes/failures of its processing. Automation history is searchable, which is helpful when troubleshooting why a particular piece of data wasn't processed as expected.
The APIANT system features a graphical automation history view that shows exactly where a problem occurred:
Automation Logs
Every time an automation is executed, the APIANT system keeps detailed logs for each trigger and action that is processed. These logs allow for troubleshooting trigger and action implementations.
