Triggers
Triggers act as an initiator that starts a journey whenever an event occurs. In simple terms, it's like a waiter coming to you asking for a food order. Once received, they report it to a chef. Classifying the example in technical terms, a waiter is a trigger, the food order is an event that occurred, and reporting to a chef is a kick start of a journey.
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". 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:
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 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 deal with.
Polling triggers periodically check for the defined events occurring in the specified app. The time interval to check for the updates is 50 seconds.
Each poll executed at 50 seconds 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 50 seconds.
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 of time.
Scheduler 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 those chunks of data arriving at a specific time slot. Click here to know more.
A callable trigger results in an 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.
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.
