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.

Hi Everyone,

I have a trigger with a dynamic input dropdown. Based on the selected value of the dropdown the output of the trigger will change. performList perfectly returns sample data based on the selected input value, but I’m having trouble figuring out how to provide static samples. I tried to use a function with a static map, but as far as I can tell sample needs to be an object not a function:

 

const sample = async (z, bundle) => {
  let samples = {
    "dropdown_value_1": {...},
    "dropdown_value_2": {...}
  }
  return samplessbundle.inputData.selectedDropdownID];
};

 

This is the validation error I’m getting when I use a function:

 

App.triggers.activity_occurred.operation.sample │ is not of a type(s) object

Your integration is structurally invalid. Address concerns and run this command again.


I was wondering how the trigger needs to provide static samples?

 

Many Thanks

Alex

Static samples are generally just hard-coded json. They represent fields that are guaranteed to be present in every response, for every user. Static samples are then used when creating Zap templates, where the author is building field mappings that have to work for everyone. We’ll also use it for validations, like a schema - if we spot your API missing something defined in the sample we’ll show you an error in the dev environment.

 

So any dynamic, user-specific, fields won’t work. In most cases the user will only interact with the samples returned from your API in your perform. Generally, users will only interact with the static sample if they cancel the test step in the editor.

Thank you so much for the response @Zane . If that’s the case, I wonder how fully dynamic triggers such as New Spreadsheet Row in Google Sheets would work where the data format completely depends on the columns of the spreadsheet selected by the user at the time of setup? That’s the functionality I am trying to implement. 

Some of our highly dynamic apps (say, form apps) have very thin static samples for some triggers and/or actions. Like, an id, name, timestamp may be the only universally included elements, so that’s all that’s in the static sample. The user experience in the editor is really based on the live samples you bring back, so this is ok. 

Really insightful question. Certainly something I’ll note that we need to spend more time on as we rework our docs.

Best advice, generally, is to configure and run Zaps with your integration in the Zap editor like a user would, watch your logs and task history, and you’ll get a better sense of how what you’re building is getting used, and validate that you’re producing a good experience for your users.

Thank you so much for the response @Zane . I totally agree with you

The user experience in the editor is really based on the live samples you bring back

 

In my opinion, most of the time, if not always, when the API is not reachable (or when the user chooses not to test their Trigger), the static template wouldn’t add much value to the user. I personally found them a bit redundant and confusing to be honest. I believe they are only useful when they are 100% matched with the actual schema which is not the case for applications with dynamic nature such as forms.

 

Once again, thanks a lot for the quick response. 

That said, static samples are really important for reasons beyond the immediate user experience in the editor.  We require them for integrations to get published in the app directory. For others reading this, please be thoughtful about your static samples - the effort will pay off for Zap sharing, validation support and other operations.

Terms & Conditions