I have an initial node that I’m trying to build a more complex Zap from, but can’t get it to show the newly created single ticket from the Specific service board I’m filtering to (selected from list, not typed manually). The test data being presented is from all boards, not just the one specified in the filter. I have to assume this trigger grabs all, then post filters based on this behavior rather than pre-filtering to grab only data from the subset of new tickets defined by the filter. This prevents me from using that ticket as test data for creating the nodes that follow it.
Is there a better way to get test data that is useful to the Zap development process?
I’m new here, but have been writing code since the 70s with 30 years in the Industry and 15 years pushing more toward toolset integration devleopment. As such, I make assumptions about the code behind these “no code” interfaces based on how I would have written them.
Based on the RestAPI for CW, you should be able to pre-filter which would also have the benefit of reducing amount of data to transfer and reducing CPU/MEM load on your systems which would also make them faster.
Page 1 / 1
Hi @ColeMcDonald
Help us have more info about what you are referring to by posting screenshots showing how your Zap trigger step is configured in EDIT mode.
When I shift to “Test”, it pulls records from all the boards, which means the one I need is unavailable, even given a large set of “Load More” clicks. Even using “Specific Service Ticket Filter” doesn’t provide the specific ticket I’ve created to use as my test case.
Can’t get past the first node with test data to be able to produce the rest of the Zap:
Very frustrating as a new user to immediately hit a roadblock on the first step. Adding this to a ticketing system that has been in place for years makes the development harder as the nodes load starting with ticket ID# 1… we’re on 90K plus at this point, so that’s (as mentioned in the thread linked above) a few years of clicking to load the test data just to get to step 2 where I tried adding a filter as you had suggested in the thread from three years ago.
@ColeMcDonald
Some Zap app integrations only return recent/representative records for the TEST tab.
Give this a try…
Add a temp Filter as Zap step 2 with a condition that will never pass.
I’m working on getting the rest of the nodes to say they’re “complete” to be able to run the test. If the devs read this, being able to split the flow at some arbitrary point, or disable nodes temporarily for cases like this where we need to use a hacky workaround to get the info I need to use to dev with would be useful.
Side note: I’ve built a career around hacky workarounds, so I don’t mind them… just shouldn’t be necessary in an ideal world. Ask me about date/time strings in Applescript sometime.
That didn’t grab the results I needed. The node indicates Service Ticket ID, but I need Project Ticket IDs… I do see Project IDs, but those are parents of the tickets.
I changed the action node to “(Both) - New or Updated” temporarily and made a change to the ticket to cause it to trigger.
There is no indication that it triggered an action for the Zapier platform. So far, this doesn’t seem to be able to gather the information needed to produce the integration between platforms I need.
I’d hate to have to write this all from scratch, but unless I’m missing something about Zapier, it seems as though it may not be a fully implemented integration with CW Manage.
Changed a few things, republished, re-updated the ticket. Got it to show up in the list. Not sure exactly what I did that made it show up… but can carry forward with the testing. Thank you.
@ColeMcDonald
FYI: Most Zap app integrations are created and managed by the app developer (CW Manage) using the Zapier Developer Platform.
Zap trigger: CW Manage - New/Updated Ticket
Description: Triggers when a serviceticket is created and/or updated.
