Triggers
Kick-start your workflows by configuring the apps that support trigger events—either real-rime or polling. Identify the types of triggers that Quickwork supports as each has its own functionality.
Triggers act as an initiator that starts a journey whenever an event occurs. In simple terms, it's like a waiter asking for a food order. Once received, he reports it to a chef. Classifying the above example in technical terms:
Trigger event: Customer placing an order
Trigger: A waiter takes an order and reports to a chef
Action: A chef prepares the food
Journey execution: Customer is served successfully
Let's consider an example to dig deeper. "Whenever you send a message on the Facebook Page via Facebook messenger, the content of the message will get sent to your email via Gmail":
Trigger event: A user sends a new message on Facebook Page
Trigger: Facebook Page trigger receives the message and forwards it to Gmail
Action: Gmail extracts the content of the message and sends it to a specified email address of a recipient
Journey execution: The recipient gets the extracted message content successfully
Here, whenever you send a message on the Facebook Page via Facebook messenger is the event we have defined. So, our Facebook messenger trigger will keep checking for the message, and as soon as an event occurs, the trigger will fire off the journey and send the message content on email.
Depending on the Quickwork APIs available, there are two types of triggers that keep monitoring the events. The first type of trigger keeps a real-time check, called webhook or real-time triggers. The other set of triggers keep polling the app at a definite time interval and then fires off the data in a batch. These are called polling triggers.
Let's take a look at this diagram and understand the trigger mechanism:
Trigger mechanism
As we have already discussed, we have two types of triggers that capture the data and send you the notification depending on their nature of execution. Let's study them in detail.
Real-time/webhook triggers
Real-time triggers are continuously executing in the back-end to look for the arriving data. As soon as the data arrives, real-time triggers send the notification at a quick glance as per the defined event. This trigger supports the asynchronous notification mechanism, which means there is no fixed time slot for the notification message to occur. It entirely depends on the occurrence of the specified trigger event.
Webhook is another important mechanism as Quickwork real-time triggers are built using user-defined HTTP callbacks, similar to a webhook. 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. Also, webhook triggers eliminate sending multiple requests just to check whether the trigger event has occurred or not. It sends a single request for a single event, thus executing the process faster. In this way, you have your data or task ready to be dealt with. Look at the following example of a real-time trigger:
Scheduler by Quickwork and Callable trigger obey the basic concepts of a real-time trigger.
Scheduler by Quickwork
Scheduler by Quickwork keeps looking for an event periodically at specified intervals i.e., minutes, hours, days, weeks, months, and years to trigger accordingly. It's a customized alarm system that Quickwork has built, enabling users to deal with chunks of data arriving at a specific time slot. Click here to know more:
Callable
A callable trigger results in the execution of two or more journeys on a single click. A super complex journey with a trigger as Callable containing many actionable steps can be called by another journey easily that contains the same Callable feature in the action steps. Thus, a parent-child relationship is maintained while executing a journey.
Child journey: A journey with a trigger as Callable containing the set of actions to be used commonly
Parent journey: A journey containing Callable in the action steps
Click here to know more.
Polling triggers
Polling triggers periodically check for the defined events occurring in the specified app. The time interval to check for the updates is 1 minute.
Each poll executed at 1 minute may return a single or a batch of data to deal with. As this trigger doesn't rely on a real-time check, there are possibilities of bulk data accumulation. For example, fetch all JIRA tickets and send an email via Gmail. According to this use case, the journey keeps running continuously, and the JIRA polling trigger periodically keeps fetching the tickets every 1 minute.
In case the journey execution is terminated, the trigger will eventually stop fetching the data. Once the journey is restarted, the trigger starts fetching the data from the point where the journey was stopped and will send you an email for the new JIRA tickets received after that point in time. Look at the following example of a polling trigger:
Trigger behavior
The behavior of Quickwork triggers is FIFO in nature. The event with the oldest timestamp, present in a queue, gets triggered first. The pointer associated with queuing events keeps a record of which events have been fired off and which events are yet to be. In this way, the duplication of the data gets neglected.
Last updated
