Integrations are not helpful if they don't run when needed. In the earliest days of integrations, most integration executions were kicked off by humans. That is, a person was necessary to initiate the code execution to transfer data from one system to another. And there are still times when we need to kick off an integration by manually invoking it.
But that's not the most efficient approach in most scenarios. Instead, we build the starting logic directly into the integration via a trigger. This trigger is part of the integration but depends on something outside the integration for its execution.
Here are the ways you can start an integration flow within Prismatic:
- App triggers
- Universal webhook triggers
- Scheduled triggers
- Management triggers
- Cross-flow triggers
"Ok," you might say, "having these trigger types seems nice, but why are they important?" They are important because different integration triggers are necessary for different integration scenarios. For example, if you need near-real-time data from a system, then starting your integration with a scheduled trigger won't do, while using a webhook or polling trigger probably makes the most sense.
Let's look at each of these and consider the scenarios they enable.
App triggers
Since an integration connects two or more apps, using a data change event in one of those apps as the trigger is the most efficient approach. For many apps, these events have corresponding webhooks, but for apps without webhooks, we can still use events to get things rolling with a sub-set of app triggers called polling triggers.
Webhook triggers
Webhooks are invoked by an event change in an app and result in a corresponding payload being sent to an endpoint. Newer apps commonly use webhooks because they are an efficient way to provide real-time notifications of data changes to external systems.
For example, a HubSpot webhook fires whenever a customer signs a new contract. You can use a webhook trigger (tied to the Salesforce webhook) to start your integration flow, which then runs to update the customer record in your app to include the new contract info.
We have built webhook triggers into several of our connectors that support webhooks. Other connectors use the universal webhook trigger.
Polling triggers
While webhook triggers react to an event when it occurs, we use polling triggers to react to an event shortly after it happens within systems that don't have webhook capabilities.
A polling trigger works by polling (calling) an API according to a defined interval and asking if there's anything new. If the API has no new data, the trigger sleeps until the next time it polls. If the API has new data, the trigger runs and starts the integration.
To ensure the integration knows what new means, the polling trigger stores a cursor of the last record, timestamp, etc.
We've begun building polling triggers into connectors that don't support webhooks, and you can also create custom polling triggers for any other apps that don't have webhooks.
Universal webhook triggers
A universal webhook trigger is based on a universal webhook. This webhook type allows you to create an endpoint that can communicate with any app via an HTTP request.
You can set things up for a universal webhook trigger so that a POST request trips the trigger and starts the integration.
This trigger enables you to create custom webhooks or even drive front-end UX in your application.
Scheduled triggers
While getting data in near real-time via webhook or polling triggers is essential in many scenarios, there are others where running an integration once or twice a day or once a week is all that's needed.
And that's where scheduled triggers come into play. This trigger isn't dependent on anything but time. It doesn't need to be notified directly or indirectly that new data is available; it just needs to run at the right time.
A scheduled trigger can be set to run according to a set interval: every so many minutes, hours, or days. It can also be set to run at a specific time, such as every day at 0700 or every week on Wednesday at 1400.
We often see our customers use scheduled triggers when they build integrations between systems that must be updated according to a set schedule, frequently because daily or weekly reports must be run after the underlying data is brought up to date.
Management triggers
We also have management triggers. In general, these cover two scenarios: deploying an integration instance or user-level config and un-deploying (removing) the same.
Instance deployment triggers
The ones tied into an instance deployment are instance deploy triggers and instance remove triggers.
Instance deploy triggers
Instance deploy triggers are set to run when an integration is deployed to ensure that everything is correctly prepared for whatever comes next as the integration runs. This setup might include creating several sub-directories in a filesystem to store incoming files, or you might need an on-deploy trigger to configure a webhook in another app, etc.
Instance remove triggers
Instance remove triggers are then used to clean up configs and other things created when the corresponding instance deploy trigger kicked off the integration. They can also notify someone that the instance has been removed, something that's often necessary for support or billing processes.
User-level config triggers
As with instance deployment/remove triggers, user-level config triggers are broken into two subcategories: those that run when a user-level config is deployed and those that run when a user-level config is removed. These are called user-level config deploy triggers and user-level config remove triggers.
The first type is used to start a flow that ensures everything the user-level config depends upon is ready, and the second type is used to start a flow to clean things up when the user-level config is removed.
Cross-flow triggers
Some integrations have a single flow. These are usually simpler integrations. However, many integrations benefit from having groups of integration actions placed into separate flows.
That's where cross-flow triggers (part of cross-flow calling) enter the equation. These are triggers that can invoke a separate flow and then pass data to that flow to get things kicked off.
These are particularly helpful in scenarios where you need to:
- Perform parallel processing for large datasets
- Organize large or complex integrations into simpler chunks
- Create reusable logic to be referenced by multiple flows
Getting to the trigger is key
In addition to having these triggers available, we also need to ensure that you are able to easily access them when building integrations on our platform. And that's why creating new integrations from scratch in Prismatic starts with selecting a trigger.
While triggers can be complex, we've abstracted much of that complexity. We did so because we want to help you spend your time building integrations and not agonizing over the minutiae of how the integration should start.
That's why we clearly define the trigger types and document precisely how they best support the integrations you build.
This straightforward trigger selection and configuration process allows you to focus on the business logic, reduce setup time by eliminating unnecessary configuration steps, and streamline integration troubleshooting and support.
Schedule a demo if you'd like to see our trigger types in action and learn how Prismatic can enable you to create powerful integrations fast for your customers.
