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.

We have a API sent up for our print management SaaS. 

We have Zaps set-up to push notifications to our team members when something moves from pre-press to production, or when something moves from pre-press to proof, etc….

 

The issue we are having is that it will send the same notification every time someone interacts with the job, so as a project moves through the production process, each time the status is changed to print or cut or fold etc…. the “This project is in production” notification is sent to the rep who entered the project.

 

Is there a way to set up the Zap to only run the first time all of the filters are true? Or something to that effect?

@LewA 

So looks like you have a set process with a number of steps like 

  • production
  • cut
  • fold
  • etc

I would have your api send the stage every time and then perform a filter test to see if it has changed. You could then send a message based on a lookup table of steps. So IF <new state> does not exactly match <old state> then send message

Then your lookup table would be something like 

State A Message = This has moved to production

State B Message = This has moved to Cut

State C Message = This has moved to Fold

and so on.

 

Hi @LewA 

Another approach might be to log each of these into a GSheet or Airtable that can be used check against before deciding whether the Zap should continue.

@LewA

So looks like you have a set process with a number of steps like 

  • production
  • cut
  • fold
  • etc

I would have your api send the stage every time and then perform a filter test to see if it has changed. You could then send a message based on a lookup table of steps. So IF <new state> does not exactly match <old state> then send message

Then your lookup table would be something like 

State A Message = This has moved to production

State B Message = This has moved to Cut

State C Message = This has moved to Fold

and so on.

 

Thanks for the response! This is actually is how it is set-up, and what the actual issue is. It’s set up essentially as IF it was in Pre-press AND now is in production, send the notification. The issue is, the API call sends each production step as “in production” and all of them were previously in pre-press at some point, so it just repeats the notification per step, which it the challenge I am trying to solve or get around.

I was hoping that there was something I was missing that would essentiall “say” IF it was in pre-press AND then moved to production AND no notifications have been sent for this job number, push the notification, ELSE do not run (or something).

 

Hi @LewA 

Another approach might be to log each of these into a GSheet or Airtable that can be used check against before deciding whether the Zap should continue.

Thanks for the response! This, although would certainly work in general - there are (2) major hurdles.


1.) Compliance - having client information housed in multiple places in a SOC-2 compliance nightmare.

 

2.) We produce 1,000’s of projects monthly, with each project seemingly being sent to the API call multiple times throughout the process (which is essentially the issue) that spread sheet would very quickly be 100’s of 1,000’s rows large, and managing / archiving / culling that information seems like more work than just writing an email to inform our team, their project hit production or is ready for a proofing….

Terms & Conditions