Skip to main content

I asked this a while back (about 3 months ago) and the issue was “solved” and we put that in place, but it does not really work the way we want and I just now got tasked with it again, so I am back. 

I have several ZAPs that connect webhooks to CRMs and ticketing systems for clients. These are simple API integrations and have no error checking. This was done on purpose. 

When a ZAP fails, it shows in the ZAP history. I would like to use another ZAP to monitor those and should one be stopped with an error, then notify either me or my client with the payload from the webhook that triggered it. 

 

The solution given to us three months ago does not give us what we are looking for. Zapier manager does “catch” errors, but …..we need access to the payload being delivered. Remember, a “webhook” always returns a success and we are using the webhook zap to simply things for our developers.  

Per the Zapier Manager, this should trigger when an account encounters an error...

 

… and it does. Below is the example data: 

 


The issue is that there is nothing we can send to our client. The “task_history_link” is to our Zap task history and our target (client) would not have access to that. It is the same with the zap_link. When the Zap fails, we email the error to our ticketing system and to the client. Once an error occurs and we are notified, we can go into the Task History and find it. These are great for us to troubleshoot, but not for our client to figure out what lead (CRM) or Ticket (ServiceNow) might have failed.

We got two notifications yesterday. Going to the Task History on our account, I found them:

 

When I click on the stopped task, I can see the data out. That has the essential information that we would like to send to our client, so that they could process it manually. Why? Because I cannot edit the payload and fix the error and retry it and it would just fail again (in this case, it was failing because the CRM was expecting an email address and it was malformed).

 

This is the outbound task payload, but does not appear to be accessible by “Zapier Manager” (for either “New Zap Error” or “Zap Turned Off”).

Is there a tool/zap that will do this, or will we have to look at writing our own (using CLI?) ? 

@Jim 

You’d need to create your own tool here I think.

Alternatively, Zapier might be able to access and send the payload data manually on a case by case basis if you write to their support - but I can see why that would not be very sustainable.


@Jim

You’d need to create your own tool here I think.

Alternatively, Zapier might be able to access and send the payload data manually on a case by case basis if you write to their support - but I can see why that would not be very sustainable.

 

Yep. I was thinking the same thing. I mean, I know Javascript/Node.js…. and always wanting a new tool in my tool belt, so this might be fun. My problem is that I’m already spinning many many plates and I am not sure I can spin another. 

As for Zapier support, there is o reason to bother them each time. I can SEE the payload when i open “Task History” from the browser. It is THOSE objects I want to be able to see through Zap manager or some other “Zapp”. 


HI @Jim!

As a possible workaround (going out on a limb), you can try adding a filter after the step that’s failing, indicating to only continue if a field of your choice does not exist. So let’s say the output usually includes an ID, you could say to continue if the ID doesn’t exist. Then you add a step with the data that came into the webhook step.

I’m not 100% sure if the filter will allow the Zap to continue if it’s running into an error, but I thought I’d throw that out there in case you wanted to test that out! If you do give it a shot, I’d love to hear whether it worked :)


HI @Jim!

As a possible workaround (going out on a limb), you can try adding a filter after the step that’s failing, indicating to only continue if a field of your choice does not exist. So let’s say the output usually includes an ID, you could say to continue if the ID doesn’t exist. Then you add a step with the data that came into the webhook step.

I’m not 100% sure if the filter will allow the Zap to continue if it’s running into an error, but I thought I’d throw that out there in case you wanted to test that out! If you do give it a shot, I’d love to hear whether it worked :)

Tried that… once it fails, there does not seem to be any control. the error halts the process.