Just like actions and endpoints, triggers can be tested as well. You can test a trigger in your app before making it live for your users, or using it in your own integrations.

About triggers

A trigger notifies Integry about an event that takes place in an app. This is the activity that starts the flow. You can learn all about triggers here.

A trigger uses an incoming endpoint. These endpoints cannot be tested separately. By testing the trigger itself, you are testing the endpoint’s response and functionality as well.

Testing a webhook-based trigger

For this type of trigger, let’s say that you have implemented a trigger for Person Updated in your Pipedrive app. You have set up the basic details for the trigger, incoming endpoint, activity fields, auto-hooks, trigger output, etc. Your trigger is finalized and now it's the time to test it.

Once the trigger is saved, under the Triggers tab in your app menu, you can view the list of triggers. In front of every trigger’s name, you can view a Test Trigger icon as shown below.

Clicking the test trigger button will open a test interface below the list of your triggers. This interface looks like this:

You’ll need to select your Pipedrive account in the Connected Account dropdown. If you haven’t added your account yet, you can also add a new account from the same dropdown. Once you select an account, you’ll be able to start the test. If your trigger has any required activity fields where you need to specify the data that needs to be sent to your app, those fields will appear here. You can then provide their values.

For the trigger in our current example, there aren’t any required activity fields. So no fields will appear and you can click on the Start Test button right away. 

Test results

Once you start the test, at the bottom of the test form, the status of the call is displayed along with a message. It tells us whether the trigger has successfully run or not. It can display both a success or an error message, depending on your trigger’s configuration.

If the trigger runs successfully, you see the message that the pre-save hook has been executed, telling us that the webhook subscription for this particular event has been created. This is shown below. 

You can see the details of this pre-save hook by clicking the arrow icon on the right. That will show you information like ‘webhook ID’, raw webook response, request headers, etc.

Below the pre-save hook information, a message appears with a waiting symbol. This tells you that the test is now running and is waiting for the trigger’s response from the third-party app. In the current case, it is waiting for you to update a person’s information in Pipedrive; so that the trigger can receive its response information and show it to you. Once you perform the activity of updating the person in Pipedrive, another success message will be shown to you. This time, it will be the trigger's response, as indicated on the right side of the success message. This is shown below. 

You can view the details of this response just like the first one. Once you click the arrow icon on the far right, another form will open as shown below.

Let’s talk about the individual elements of the above test result: 

Time Stamp: Displays the exact time and date for when the response was received. This can be a few seconds to a few minutes after you performed the activity. There’s always a small window of time taken in receiving the webhook. Also, the time zone here depends on the settings of your system.

Response Header: This shows the header details attached to your trigger’s response. This can be something like content type (format of the response), which is normally JSON. For our current example, there were no headers that affected the response. So this field is empty. 

Endpoint Response: The actual response of your trigger that is returned through the incoming endpoint. This contains all the values related to your trigger’s event. In our current example, it contains the new attribute values of the person that was updated.

Object Output: If your trigger uses objects to represent its output, that object response will be shown here. For the trigger in the current example, no object has been used to modify the response, so this field is empty.

You can also copy any elements from your response fields to your clipboard. This can be done by hovering over to any line in the response and clicking on the copy icon as shown below. 

You can copy the complete response or just a single line. The data would be copied in standard JSON format. 

After your trigger returns you the response of your activity, the test will keep running. That means it will keep waiting for any further incoming trigger responses. You can perform as many activities that trigger a response here and the test will show each of them, given that they’re successfully received.

Once you’re done testing out your trigger, you can stop the running test by clicking the Cancel at the bottom. 

Testing a poll-based trigger

The process of testing poll-based trigger has many steps similar to the above method. For this method, let’s use the example of Contact Created trigger for the app, ActiveCampaign

The process leading up to the test interface is the same. You have to completely set up your trigger, go to the triggers tab in your app, and click on the test trigger icon in front of the trigger. A test interface will open up as shown below. Again, you will have to add or select your ActiveCampaign account. After adding your account, any activity fields that might be required for your trigger to work will appear here and you will need to provide their values.

Once you provide your account and the required fields information, you can click on the Start Test button.

When the test starts, you’ll see a message informing you of collecting baseline data. This is the information being gathered for the baseline poll. Before we move on, lets first discuss the terms Baseline poll and Change poll.

Poll: Better explained here, a poll is when Integry makes a request to check the status of an event in an external app for information. One poll is run after set time intervals to check for new information relating to the event.

Baseline poll: The first ever poll performed on initializing a test, or creating a new integration is called a baseline poll. It’s known as baseline because it is the initial state of your data. Any change afterwards can be tracked by comparing it with this baseline data.

Change poll: Any poll performed after the baseline poll is a change poll, regardless of an actual change being detected in it or not.

So the message, “Collecting baseline data” tells us that the information is being collected for the baseline poll. 

Test results

Once the baseline poll finishes running, the status of the call is displayed along with a message. This informs us of the baseline poll being successful or not. Again, this depends on your trigger’s configuration.

If the baseline poll is successful, you can see the response of the baseline poll as shown below.

Clicking on “View Results for Baseline Poll” will show you the details of this poll’s response. This will contain information like poll URL, endpoint request headers, and poll parsed response. For our current example, the poll response field will contain the information of the contacts that are already present in your ActiveCampaign account and list.

Below the baseline poll information, you’ll be able to see another message. This will tell you to perform the trigger-related activity in the external app and run the poll again. So you can create a contact in ActiveCampaign and click the Start Poll button to run the change poll.

Once you click the Start Poll button, the test form will start waiting for the trigger response. This can be seen below.

After a short duration, this change poll will finish running and a success or error message will be displayed for it. For our current example, this is shown below.

This change poll’s details can also be seen by clicking the View Results button. This will contain all the basic poll information, as well as the new information that was added. These details are shown below. 

Let’s discuss the new fields here individually:

URL: The URL on which the poll request was made.

Poll Endpoint Request Headers: The headers that were attached along with the poll request. This again depends on the app’s documentation. In the current example, it contains the token for API-key authorization of the ActiveCampaign account.

Poll Parsed Response: This contains the complete response of the poll request for this trigger. It contains all the contacts that are currently in your ActiveCampaign account. It includes the new contacts that you added for the test, as well as the previous ones from the baseline poll.

Trigger Response: This response shows you only the data specific to the event that this trigger is for. In the current example, it will show you the data of any new contacts that you have added in your ActiveCampaign account and the selected list. So this field shows you any change that has occurred relating to your event.

Trigger Object Output: If your trigger uses objects to represent its output, that object response will be shown here. For the trigger in the current example, the new contact(s) added will be shown as object(s).

After your trigger returns you the response of the first change poll, the test will keep running. So the test interface will keep waiting for any further incoming trigger responses. You can perform more activities related to this trigger’s event, and click on start poll again to receive their data in response. All the new polls will be change polls.

Once you’re done testing out your trigger, you can stop the running test by clicking the Cancel button at the bottom.

This was everything you needed to know to get started with testing your triggers. Learn how to test other app components like endpoints, authorizations, and actions.

Did this answer your question?