App Event Triggers

A flow with an app event trigger runs when some data changes in a third-party app. For example, you may want to be notified when an Asana Project is created, updated or deleted, or when a PagerDuty Incident occurs.

If the connector you're working with does not have a built-in app event trigger, you can leverage the universal webhook trigger to receive event notifications from a third-party app or the schedule trigger to periodically check for updates from the third-party.

What are app events?

You want your flows to run when data is updated in a third-party app. There are two way to detect changes to data:

1. The app notifies you of a change via a webhook request.
2. You poll the app for changes on a regular cadence, like every few minutes.

App event triggers with webhooks

Some app event triggers receive update notifications from the third-party app via webhook request. You'll need to configure the third-party app to notify you when changes occur. This can be done in one of three ways:

1. Some triggers are built to configure webhooks in a third-party app when an instance of your integration is deployed, and remove webhook configuration if the instance is deleted. Examples of those triggers include Asana's Workplace Projects Trigger or PagerDuty's Incidents Trigger.
2. Some triggers are built to receive webhook requests, but you'll need to build logic into a deploy flow that configures the third-party app to send requests to another flow. You can see an example of that in the Gmail connector.
3. Some apps do not allow you to configure webhooks programmatically. You'll need to display the instance's webhook URLs in your config wizard, and have your customer manually configure webhooks in the third-party app using these URL(s). Or, you could use polling triggers to poll for changes.

If you are integrating with an app that sends all of your customers' webhook requests to a single endpoint, see Single-Endpoint Webhook Integrations.

To build your own app event trigger in a custom connector that supports webhooks, see instance deploy and delete events for triggers.

App event triggers with polling

Some apps do not support webhooks, or webhooks configuration is tedious to configure. Polling triggers are handy when you want to be notified when data changes in those apps.

A polling trigger will poll an external API on a schedule that you set (for example, "every 5 minutes"), and if new data is available since the last time it polled, a full execution will run so your flow can process the data.

Some sort of cursor is stored internally on the trigger. The cursor might be an ID of a record that was last seen, or an "Updated At" timestamp. The cursor acts as a "bookmark" so the triggers knows what records to fetch the next time it runs.

Set an interval that is longer than the time it takes to run your flow

Like other persisted data, your trigger's cursor is loaded when an execution starts, and is written out with the execution finishes. If your flow takes 10 minutes to run, and you configure your trigger to run every 5 minutes, the second execution will fetch and process the same changes that the first fetched, since the first didn't finish before the second began.

To ensure that you don't double-process data, set your poll interval for longer than it takes for your flow to run.

Note that an execution runs each time a polling trigger looks for new data. If no new data is available, the execution immediately stops, and no additional steps run. If you navigate to an executions screen, you can filter executions that found no new data to process by clicking Filter and selecting Exclude executions without trigger-detected changes.

Examples of connectors that implement polling triggers include Dropbox and Google Drive.

To build your own app event trigger in a custom connector that supports polling, see the Custom Triggers article.