Skip to main content

Get Support
Have a question? Let's get you an answer!

How Do I...? Troubleshooting Code & Webhooks Developer Zone

Other Help Resources
Wait, there's more! Check out these Community sourced spaces for additional resources.

Zapier Help Center Hire an Expert

Learning Resources
All of our best learning resources can be found here.

Featured Articles Show & Tell Zapier's products AI Hub Zapier Tools Hub

Share your knowledge
Give back to the Community by sharing your automation wins and helping to answer questions.

Share your success See unanswered questions User Groups

Other Learning Resources
Some of our favorite additional ways to upskill your Zapier knowledge.

Zapier Learn Zapier Blog Zapier Webinars

Product Updates
Check out what is new and upcoming with Zapier with our regular product updates.

Product Updates

Early Access Program
Want to join Early Access? Learn more here.

Best answer

Sample "Test Trigger" Data: Use "live" test data or "real" dummy data?

M

We are in the process of building out an app for Zapier. We cannot decide which is the best practice in showing Test Trigger Data:

Live Trigger Data: We have noticed that we can either pull the live trigger data IF the event was triggers right before building the Zap

  • Pros: it is a True test trigger, making the user feel they are successfully building the Zap correctly
  • Con: If the user does not know they have to perform the event right before setting up the Zap, they will not get test trigger data and might think something is wrong with their Zap. 

OR 

“Real” data: we can always populate the trigger data with real data based on the end user’s account, but it might not be an event that triggered the data (for instance, imagine setting up a Google Sheet “new row added” trigger: If there is a row that already exists, we pull that data in to show as “test trigger” data)
 

  • Pros: You (almost) always have “real” Trigger Test data that is directly from your account to use to continue to the Actions
  • Cons: If you are expected to get the data you just performed the event on, you might not get that exact event data and may think your Zap isn’t being set up properly. 

TL’DR: Should we use Live Trigger Data as Test data OR Should we use pre-populated data from the user’s account? What is the best practice? 

Best answer by ZaneBest answer by Zane

Good question, touching several of the fundamental design questions as you create a great user experience implementing triggers with rest hooks.

 

First, you will want to implement performList (“real data” in your question) and use this endpoint to pull in the data your users will use to map fields in the Editor with, as opposed to relying on your hook mechanism to push an event for this purpose. If you’ve ever set up a trigger with a rest hook endpoint that didn’t implement that performList you know the experience is usually brutal for the user - they have to go to your app open in a separate tab, and while the Zap test step is running switch over to your app to do the thing that generates the hook event within the window of time the Zap Editor is sitting there waiting for some data. It’s not great for most users. This is why we require rest hook triggers implement performList for all new integrations that get published into the App Directory. 

 

You are 100% spot-on to be thinking of your trigger design as being about events, rather than being about the data, per se. But your interaction with the Zap Editor is about getting the user data so that they can effectively set up fields mappings from your trigger into subsequent action steps.  In other words, getting the Zap ready to handle the events in the future, based on data from the past.

Also, less abstractly, if your performList can hit an endpoint that provides data in reverse chronological order, you’ll get the most recent stuff and the experience should be very similar, if not identical.

Next challenge may be that the data returned by performList needs to match what the hook is going to send when the Zap is running. Sometimes the hook data definition and the resource you get back from a GET endpoint don’t line up. In this case you’ll have to do some data massaging in your Zapier handler code to reconcile them. All the fields that will be available when the Zap runs will need to be available in the performList result, with the same names and data shape, or your users won’t be able to map the fields successfully.  I can expand on this point if that didn’t make sense.

 

Also, as a general statement, we see users are more successful at field mapping when they recognize their data, as opposed to random fake sample material. 

View original
    Did this topic help you find an answer to your question?
    This post has been closed for comments. Please create a new post if you need help or have a question about this topic.

    3 replies

    Z
    Forum|alt.badge.img+9
    • ZaneZapier Staff
    • Zapier Staff
    • 331 replies
    • June 11, 2021

    Before answering I wanted to clarify if you’re building a rest hook trigger or a polling trigger - just to make sure I understand your question properly.

    M
    • mkh011Beginner
    • Author
    • Beginner
    • 1 reply
    • June 11, 2021

    Great follow up - we are building rest hook triggers, but polling an HTTP endpoint for the sample “test trigger” data. Our webhooks only provide a minimal about of data and therefore require an additional HTTP API call to get the test trigger data

    Z
    Forum|alt.badge.img+9
    • ZaneZapier Staff
    • Zapier Staff
    • 331 replies
    • Answer
    • June 11, 2021

    Good question, touching several of the fundamental design questions as you create a great user experience implementing triggers with rest hooks.

     

    First, you will want to implement performList (“real data” in your question) and use this endpoint to pull in the data your users will use to map fields in the Editor with, as opposed to relying on your hook mechanism to push an event for this purpose. If you’ve ever set up a trigger with a rest hook endpoint that didn’t implement that performList you know the experience is usually brutal for the user - they have to go to your app open in a separate tab, and while the Zap test step is running switch over to your app to do the thing that generates the hook event within the window of time the Zap Editor is sitting there waiting for some data. It’s not great for most users. This is why we require rest hook triggers implement performList for all new integrations that get published into the App Directory. 

     

    You are 100% spot-on to be thinking of your trigger design as being about events, rather than being about the data, per se. But your interaction with the Zap Editor is about getting the user data so that they can effectively set up fields mappings from your trigger into subsequent action steps.  In other words, getting the Zap ready to handle the events in the future, based on data from the past.

    Also, less abstractly, if your performList can hit an endpoint that provides data in reverse chronological order, you’ll get the most recent stuff and the experience should be very similar, if not identical.

    Next challenge may be that the data returned by performList needs to match what the hook is going to send when the Zap is running. Sometimes the hook data definition and the resource you get back from a GET endpoint don’t line up. In this case you’ll have to do some data massaging in your Zapier handler code to reconcile them. All the fields that will be available when the Zap runs will need to be available in the performList result, with the same names and data shape, or your users won’t be able to map the fields successfully.  I can expand on this point if that didn’t make sense.

     

    Also, as a general statement, we see users are more successful at field mapping when they recognize their data, as opposed to random fake sample material. 

    M
    1 person likes this
    • M
      mkh011
    Terms & Conditions