Web service eternal loop

6 Comments

  • Andrew J
    Community Moderator

    Could you add something to the API update so that your trigger can recognise this instead.  eg. Add a hidden or small 'updated via xxx' text which you can then use as a 'is not present' condition.

     

    0
  • Andrew J
    Community Moderator

    Regarding the tag, you could set a tag, but have that tag removed by an automation that cleans up in the next cycle.  You would want to be careful here though as if it runs at the same time as an incoming update, you may strike some issues.

    0
  • Chris Garone

    Thanks for the suggestions.  I have explored setting a tag or a custom field value to essentially "lock" the ticket to keep it from being updated by a web service.  However, since the ticket can't be permanently "locked," I need a way to remove that tag or custom field value in a predictable and timely way.  Automations run every hour and that isn't timely enough for our purposes.

    In our setup, we could rely on detecting the user/agent that is requesting the ticket update.  That would be a good solution as the particular web service I would like the trigger to ignore is always run by the same user.  However, I have not found a condition that captures/checks the user/agent that is updating the ticket.

    Is there such a condition?  If so, can you advise me as to which condition I can use to detect the user that is updating the ticket?

    Thanks again.

    0
  • Brett Bowser
    Zendesk Community Team

    Hey Chris,

    If I'm understanding you correctly, there should be a condition titled **Current user > is > (agent)/(end-user).

    Does that get you the results you're looking for?

    Let me know!

    0
  • Chris Garone

    With my particular use case, I was able to solve my issue by creating a trigger condition based on the user/agent that runs the API call.  In fact, I had to create two triggers.  The first trigger ignores ticket updates by the user that sends the API call.  The second trigger fires if the user is the user that sends the API call AND it is not updated via Web Service.  The second allows the user to login and make manual edits to tickets.

    I very much appreciate your help in this matter and I would like to give some feedback on my experience.

    It would be great if Zendesk triggers could somehow differentiate between web services with the updated via Web Service condition.  The fact that the bulk ticket updates and my API call were lumped together as "Web Service" was problematic.  One is an internal API call and one is external.  There should be a way to differentiate in the condition.

    Also, using user/agent conditions in triggers is not optimal since user/agents are a valuable commodity.  My first inclination was to use this type of logic with a new user/agent until I found out they cost $59 a month.  Luckily for me we had an existing user that we could dedicate to this task.  If Zendesk could differentiate between types of API calls, the dependence on user/agent would be unnecessary.

    Also, the fact that I needed to create two triggers to essentially accomplish a combined condition is slightly problematic.  It is a good work around for me because I only needed two triggers.  If my use case required more complex condition logic, I would have had to create many triggers.

    I agree with the posters in the following thread that a good functionality to add would be to allow for more complex AND/OR logic in our trigger/automation conditions.

    https://support.zendesk.com/hc/en-us/community/posts/360029921534-Multiple-AND-OR-conditions-in-Views-Triggers-and-Automations

    Again, I thank you for your attention to this matter.

     

    0
  • Brett Bowser
    Zendesk Community Team

    Thanks for taking the time to share this Chris!

    0

Please sign in to leave a comment.

Powered by Zendesk