Triggers determine what event to look for in order to execute the actions described in a Recipe.
Trigger events can be set off in apps (e.g. Insightly, JIRA) when a certain event happens (e.g. new Contact is created, an existing Ticket is updated) when a new line is added in a file, or according to a schedule (fires at a certain time or interval), etc.
Depending on the available API, AppConnect can receive trigger events in real-time, or check for the occurrence of an event periodically by polling the app.
Triggers can be classified into different types based on when they check for new events (trigger mechanism) and how they group new events (trigger dispatch).
AppConnect Recipes pick up and queue trigger events in sequence to be processed as Recipe jobs. The Recipe maintains a cursor and progresses through the trigger event queue synchronously, with an adjustable throughput.
No duplication of jobs occurs as AppConnect maintains a record of the trigger events it has seen. AppConnect triggers have the following behavior.
In-sequence delivery - Triggers will be delivered in chronological order, e.g. oldest records will be processed first, or in the sequence they were delivered to AppConnect.
Durable cursor position - Recipes remember the jobs it has processed even across stopped and running states. Whenever a Recipe is started, it will pick up where it stopped and begin processing all trigger events since it was stopped.
No duplication - Each Recipe maintains a record of the trigger events it has seen, and will not process duplicate events.
Flow control - Recipes process trigger events synchronously, e.g. only process a second job when the first job has been completed. AppConnect provides flow control over Recipes by enabling multiple jobs to be processed concurrently.
Guaranteed delivery - For AppConnect polling triggers, AppConnect guarantees trigger event delivery. Even if servers experience temporary downtime, or if the network is unstable, AppConnect ensures that triggers are picked up and processed in-sequence.
Webhook events, which powers most real-time AppConnect triggers, inherently have the possibility of being lost.
To mitigate this, most AppConnect-built real-time triggers (a notable exception is the HTTP webhook trigger) have a backup polling mechanism that ensures missed webhook trigger events will be picked up.
Trigger mechanisms determine when a trigger will fire. In this section, we cover polling triggers, real-time triggers, and scheduled triggers.
Polling triggers check for new events by periodically querying the app to see if new events are available. The polling frequency is determined by the type of AppConnect plan and can be as low as every 5 minutes.
Each poll may yield multiple events ready for processing i.e. a single poll can result in several jobs being created.
When the Recipe is first started, the polling trigger fetches all events after the From date, e.g. "fetch all NetSuite customers created or updated since 2017 January 10am, PST".
Subsequently, polls are made at regular intervals as dictated by the plan type. A Recipe with a 5-minutes polling interval that is kept running continuously will therefore fetch new trigger events every 5 minutes, e.g. "fetch all NetSuite customers created or updated in the last 5 minutes".
When the Recipe is stopped, polling triggers stop fetching events from the trigger app. However, if the Recipe is started again, polling triggers will fetch all events since the Recipe was stopped.
Example: Polling trigger
An AppConnect account has a 5-minute polling interval, as displayed on their polling triggers.
The Recipe polls every 5 minutes for new accounts created in Insightly and fetches any new accounts. If there were multiple accounts created, each will result in a new job.
If the Recipe is stopped on February 1st, 2017 at midnight PST, it will cease to fetch trigger events.
However, when the Recipe is started again, let's say on the 10th of March at midnight PST, AppConnect will fetch all Insightly accounts created since Feb 1st.
Real-time triggers are usually built on top of an asynchronous notification mechanism.
Real-time triggers typically require registration in your connected app (either via the API or manually via the app interface) to let the app know that you are interested in a specific event.
When that event occurs, the app will send a notification to AppConnect and generate a trigger event.
Webhooks are one such mechanism. Most real-time triggers supported on AppConnect are built on webhooks.
The advantage of webhooks is that there is no delay, and it is more efficient as we only receive notifications from apps when events occur, instead of AppConnect having to check at regular intervals for new events.
Real-time triggers supported by AppConnect (this excludes HTTP real-time triggers) are generally webhooks supported by regular polling.
The polling intervals for real-time triggers are generally longer than the normal polling triggers, however, i.e. instead of polling once every 5 minutes or so, the trigger can now poll once every hour.
The polling mechanism in real-time triggers is also what allows you to select a From date at the time of Recipe start.
Scheduled triggers are executed at specified days and times, hourly, daily, monthly, etc.
At the scheduled time or interval, this trigger will fetch all events matching the specified criteria. Also, unlike other triggers, scheduled triggers will return events that have already been picked up previously.
Scheduled triggers will return events in batches, similar to how batch triggers work. Users can specify the maximum batch size, e.g. if the batch size is set to 100 and 420 new events are identified, 5 new jobs will be created. The first four jobs will have 100 events each and the fifth will have 20 jobs.
Scheduler triggers allows you to schedule when exactly your Recipe will run. There are two triggers:
New scheduled event
This trigger allows you to specify the time the Recipe should first trigger, and subsequently, the time intervals to continue triggering on.
New scheduled event (advanced)
This trigger allows you to specify the days of the week the Recipe should trigger on, as well as the times it should trigger on. If you specify only the minutes, e.g. 30, the Recipe will trigger 24 times in a day, every 30 minutes past the hour. If both hour and minute input fields are filled, the Recipe will trigger once a day.
Trigger dispatches determine whether a trigger returns a single event or a list of events. In this section, we cover single triggers and batch triggers.
Single triggers are useful for continuous real-time synchronization of data, e.g. moving Opportunities from Insightly into NetSuite as sales orders the moment these opportunities close. Most AppConnect triggers are single triggers.
Batch triggers are generally used for increasing throughput, as trigger events are retrieved in lists instead of single events, e.g. moving high volume of user activity data from Insightly into data warehouses like Redshift.
Batch triggers are similar to polling triggers in terms of how they fetch new events. This group size i.e. batch size can be specified by the end user as part of the trigger configuration.
The Since or From setting enables Recipes to fetch past trigger events from a specified date and time. i.e. instead of picking up new trigger events (events created since Recipe was started) this enables picking events that have already occurred.
In the example below, the New/updated folder in Box trigger has a from date of 01/01/2019, midnight PST.
When the Recipe is started, only folders created after 01/01/2019 at midnight PST will be picked up, as viewed from the created date column on the job report.
However, not all triggers have the Since/From parameter. For such triggers, the date and time from which trigger events will be fetched is predetermined by default, usually as an offset from the time the Recipe is started.
Common values are:
When Recipe is first started
An hour before Recipe is first started
A day before Recipe is first started. This offset is usually communicated in the trigger hint for the connector.
The Since/From value can only be set once, and will be locked from further changing after the Recipe has been started for the first time.
Trigger conditions are additional rules that define what kind of trigger events should be selected for processing, e.g. you can specify that only Insightly Contacts from California must be processed.
Trigger conditions are evaluated by AppConnect after the trigger events have been fetched. For example, AppConnect can retrieve all new Insightly Contacts created in the last 5 minutes, then filter out Contacts which are not from California.
This also means that with a New Insightly Contact trigger, Contacts that are subsequently updated to be from California will not be picked up. If you find that your Recipe seems to be missing events that you expected to be picked up, this might be the issue.
Note: trigger conditions generally do not monitor a field change, but simply check if the trigger condition is fulfilled.
For example, if you wish to sync only closed/won Opportunities from Insightly into your ERP system, setting the following trigger condition will cause every update made to the Opportunity in its closed/won state to be picked up by the Recipe.
This is as opposed to having the Recipe pick up the Opportunity only when its status is marked closed/won for the first time.
To add a trigger condition, check the Trigger IF checkbox. The trigger datatree will appear, displaying the variables that can be used to formulate the trigger condition.
Define the trigger condition. The following ensures that only Opportunities with a value greater than $5,000 will be picked up by the trigger. Values are case sensitive and should be exact.
To add an additional trigger condition, select + and choose from the OR or AND in the picklist. The selected operator will define how all additional trigger conditions will be added.
Define the additional trigger condition. Values are case sensitive and should be exact. The following ensures that Opportunities with a value greater than $7,000 will also be picked up by the trigger. Notice that from the third trigger condition onwards, trigger conditions will be combined with the previously selected operator (OR or AND).