Adding Comments via Triggers and Automations

79 Comments

  • Justin Hamilton

    It could potentially be listed as something else. When we first installed the app it was a Zendesk labs project on github (https://github.com/zendesklabs/url_builder_app) but I seem to recall that they added it to the apps marketplace at some point.

    If not, it's really easy to download the zip file from the github page and upload directly as a private app (Apps > Manage > "Upload private app").

    Give that a shot if it's not available in the Marketplace :-)

     

    0
  • Dean Taylor

    How could we get it to update the ticket subject and could we use place holders to reference custom field data in the subject?

     

     

    0
  • Jaleel Beck

    A quick question - I see trigger options such as "notify target" that don't exist in my version of the support dashboard.  Is that available based on a higher Zendesk subscription service?

    0
  • Jason Littrell

    @Dean Taylor: You can use "ticket[subject]". Placeholders will be evaluated before the target is sent, but if they are used in the URL field, then any spaces in the placeholder will be converted to plus signs. This could be an issue if you're trying to use Liquid filters to format a field value. Just remove the spaces to make sure the filters are evaluated properly, or use the "Attribute Value" field and set the subject from a trigger.

    @Jaleel Beck: According to this article, external targets are available on the Team plan or higher. To create a target, you can go to the Admin page, then select Extensions under Settings. Click "add Target" to select from a number of different target options.

    0
  • Nikola Malesic

    Hi,

    I am trying to set the http target, but my Zendesk interface is slightly different.

    I don't have this:

    • Attribute Name: ticket[comment][body]

    but rather this:

    and when trying to test the target, this is popping up:

     

    Does anyone know what should I put in there?

     

    Kind regards,

    Nikola

     

    0
  • Megan Howell

    Nikola,

     

    Although this tip mentions an HTTP target, they are actually using a URL target! Try following the steps by setting up a URL target instead :)

    0
  • Jeff Tan

    @Phil Holcombe, thanks for posting this tip.

    Works pretty well for me but I've run into an issue where posting a public comment that contains links appears unformatted.

    I tried using html and markdown and the links were not appearing correct.

    HTML links would appear in the email as <a href="link">some text<a> and markdown would appear as [text](url)

    However, when using markdown, the public comment appears formatted correctly. I am going to play around with the "notify requester of comment update" trigger

    0
  • Jeff Tan

    Looks like this only works if I update the notify requester of comment update trigger to use the placeholder {{ticket.latest_public_comment_formatted}} instead of {{ticket.latest_public_comment}}

    1
  • Jeremy Flanagan

    Help Please!!! The target is correct, but when testing the trigger fires, but doesn't actually leave a private comment:



    0
  • Jason Littrell

    Hey Jeremy.

    What's the full URL? Does it include "?ticket[comment][public]=false"? It could also be your authentication credentials. I'd recommend replacing {{ticket.id}} in the URL with a test ticket number, then submitting a test target. You'll get a transmission error if the credentials are invalid. If they are valid, you should see a message like this in your test ticket:

    Test message from Zendesk sent on: 2016-07-29 22:44:36 UTC

    0
  • Charles Magnuson

    I am unable to get past step 1.

     

    When I finally realized the initial tutorial is wrong and I should be setting up a URL target, I switched to creating that. Here's what I'm creating:

    URL target

    Title: Comments via triggers and automations
    URL: https://humblebundle.zendesk.com/api/v2/tickets/{{ticket.id}}.json?ticket[comment][public]=false
    Method: PUT
    Attribute Name: ticket[comment][body]
    Basic Authentication: left blank

    When I attempt to test the target using these settings, I receive the error "Error during transmission: HTTP client call failed":

    Can someone help me understand why the steps described on this tutorial are not working for my instance of Zendesk?

    -Charles

    0
  • Dean Taylor

    @Charles I believe the problem is that you haven't added any basic authentication.

    You need to add your username and password for your zendesk account in there.

    If this doesn't work, try username/apitoken and password

    0
  • Jennifer Rowe

    Thanks for jumping in to help out @Dean!

    @Charles, let us know if that fixes your problem. Good luck!

    0
  • Charles Magnuson

    Hey Dean and Jennifer,

    No luck. I've entered the email address I use to login to Zendesk along with the password I use to login to Zendesk and the same error appears. I've also entered the same email address along with a newly generated API token, which produces the same error message.

    The only thing I can think of that might have an impact here is that I have 2FA turned on for my Zendesk account. We also have SSO enabled if that makes a difference.

    Any other troubleshooting steps I can try?

    0
  • Charles Magnuson

    Re-reading Dean's note made me realize I should try the API token in the Username field with my Zendesk account password in the Password field. I've tried this only to see the same error message.

    It should be noted to Zendesk that copying the API token from the API settings page includes spaces surrounding the API token: " Tq9jd8OhlIlZaIKiiYVXXwytX9OzrNBucmS7bVAH "

    I was sure to remove those spaces before trying the token in the Username and Password fields on the extension creation page.

    0
  • Dean Taylor

    @Charles, not sure if I misread your latest reply(s) but did you try your username forward slash api token

    example:

    test@test.com/h4h3879h3498h3498h34

    password

    If you did try that then apologies for repeating myself. Everything else looks fine and it worked for us, we also have SSO. (FYI if you don't have SSO enabled then api token isn't required).

    0
  • Jason Littrell

    @Charles Magnuson: When using an API token for authentication, you'll need to set up the authentication fields like this:

    Username: {email_address}/token

    Password: {api_token}

    It's similar to how you would authenticate via cURL (see here).

    Also, be careful with your API tokens. If that's a live token you showed us, anyone who gets ahold of an email address linked to one of your agent profiles can use that token to authenticate into your Zendesk instance.

     

    0
  • Charles Magnuson

    Hey Dean,

    Oh wow, that part about merging the email address with the API token sure isn't clear from the tutorial. Alright, so I've given that a shot now and unfortunately the situation has not changed. I am seeing the same error message.

    Here are the details I've entered:

    Title: Comments via triggers and automations
    URL: https://humblebundle.zendesk.com/api/v2/tickets/{{ticket.id}}.json?ticket[comment][public]=falseMethod: PUT
    Attribute Name: ticket[comment][body]
    Username: {email_address_I_login_to_ZD_with}/{API_token} (written out this looks similar to this: "charles@emailaddress.com/abc123")
    Password: The password I use to login to Zendesk.

    Should this information work successfully according to your knowledge?

    ---

    Hey Jason,

    Your advice seems to differ from Dean's in that Dean says I should use my Zendesk password in the Password field while you've advised me to use the same API token in the Password field which I'm merging with my email address in the Username field. Nevertheless, I've given your method a try as well and I am still seeing the same error: "Error during transmission: HTTP client call failed"

    I appreciate the note to use care with my API tokens. I deleted the token before posting it in my comment, but that's probably still a stupid thing to do due to the risk. I'll be sure to use placeholders in the future.

    Looking at your link regarding authentication via cURL, I've noticed how the instructions there seem to say that I should login using a username which is formatted differently.

    Instead of logging in with {email_address}/{api_token} like you and Dean have recommended, Zendesk notes on the cURL page that I need to format the username as follows: {email_address}/token:{api_token}.

    Unfortunately I have tried this third method of formatting the information in the Username field with no difference in the results.

    0
  • Dean Taylor

    @charles,

    Okay, I think I figured it out, and yes I can't even remember how I figured it out originally because it isn't covered.

    I've actually got it set like this, (instead of adding the token in the username you need the word token:

    uesrname: dean.taylor@email.co.uk/token 

    Password: API TOKEN 



    0
  • Charles Magnuson

    Hey Dean,

    I feel a strong desire to kiss you! YOUR ADVICE WORKED AND I'M SO HAPPY!!!

    This has been quite a frustrating tutorial to try to work out, but your persistent help has been amazing. I can't express enough how much I appreciate it. Hell, if you email me your PayPal-associated email address I'll send you money to get a beer on me! Seriously: uzs29x01idbu7vlgjp@thrott.com

    Thank you so much for your help!

    -Charles

    0
  • Phil Holcombe

    Hi,

    Sorry if the original tutorial wasn't clear for you, and leaving others to provide some great support to help you get things sorted.

    Since I posted the original tip, we had discovered some intermittent problems with the timing of events, that Zendesk support were not able to fully resolve. In the end, we moved to a more robust model where we have separate code outside of Zendesk, that calls the Zendesk API, without the trick of cramming it all into the HTTP target.

    Phil at Nexmo, a Vonage Company.

    0
  • Jacob J Christensen

    Excellent post Phil! Saved me a bunch of time!

    0
  • Sherman Dickman

    Adding Internal Notes via triggers and automatons really should be supported by Zendesk.

    I was able to get around this by using Zapier. 

    In a nutshell, when a new ticket is created, you can then assign an action to add an internal note. 

    It's a Zendesk > Zapier > Zendesk flow. Seems to work okay.

    0
  • Harold

    Hey all,

    I got this all working (from this post mainly, thanks Jay for putting it together) but it seems that I can't use dynamic (translated) content in the automation. Did anyone else find this or perhaps have a solution?

    Background: after 28 days and sending 4 e-mails we automatically close the pending ticket with a public comment. When I use {{dc.mytranslationsforthiscomment}} in the automation the target will 'send' but without the resulting comment. Putting the text directly in the automation works like a charm, but that's not very friendly to our fellow Europeans with a different language :)

    0
  • Rebecca

    Hi Harold- 

    Using dynamic content in the automation should render as this workflow is generally using targets and tags to schedule automations to fire. Without looking at the specifics of your setup it is difficult to know exactly what may be occurring in this workflow. What renders in the outgoing email when using a dynamic content placeholder in the automation? If there is any type of error, I would recommend submitting a ticket to support@zendesk.com so we can dive in a bit further specific to your workflow and Support. 

    0
  • Harold

    Hi Rebecca,

     

    Thanks, I will, but for now I'm focussing on what James addressed: it's not working at all right now, even though we didn't (seem to) change anything. Testing the target sends testmessages to random open tickets. 

    I might submit a support ticket, but I'm  reconsidering the solution because it appears so fragile. 

    0
  • Rebecca

    Hi Harold! 

    Thanks for the update. I agree that submitting a request to Support would be an excellent next step so we can take a look at your setup and drive deeper into your workflow and the possible points of failure. I will go ahead and create a proactive ticket for you and reach out soon! :)

    0
  • Steve Morrell

    I used this as the basis of adding comments through automations. However, I have noticed that sometimes the comment is not made, though the automation fires. ZD support suggests that this can be because of race conditions, and suggests HTTP targets instead. 

    I assume that this is the "timing issue" that Phil mentioned.

    Nikola on July 25 tried this as a HTTP target, and asked what text needs to go in the automation. Can anyone advise on this, as this is the issue I have now.

    I'm thinking:

    {"ticket": {"comment": {"public": false, "body": "blah blah blah"}}}

    I also second that this needs to work out of the box. We use automations to close tickets from unresponsive customers, and need the comments as an audit trail. If these are not trustworthy, that is a major issue.

    0
  • James

    @ Steve - I ran into what I interpreted as timing problems with both URL Targets and HTTP Targets.  I use triggers to add 2 types of public comments, add private comments, send automated emails with instructions for end users as well as performing other custom field updates.  In certain cases, multiple updates need to be made on a ticket at the same time.  During testing I found very inconsistent results when triggers made multiple API calls at same time (i.e. 2 different sets of conditions were met and 2 triggers with HTTP Targets were fired) - all I could surmise was that the API calls were being made simultaneously and while the trigger appeared to run...the API call was not always being executed.  I have no idea if this is accurate or not...but I decided to create trigger conditions that followed a stepped process whereby 2 API calls would never be made at same time on an individual ticket.  By using various ticket properties (created vs updated vs updated by API), values in custom fields being present / not present and by setting and removing tags with each stepped trigger - I was able to workaround the problem I was having.

    An example of the HTTP Target and JSON used when my trigger calls that HTTP Target are below:

    HTTP Target Properties
    Title:  Ticket Update
    URL: https://YOURDOMAIN.zendesk.com/api/v2/tickets/{{ticket.id}}.json?
    Method: PUT
    Content Type: JSON
    (authentication is via username/token with ZenDesk generated token value as password.

    JSON
    {"ticket": {"comment": {"public": false, "body": "Thanks, this is now solved!"}}}

    In general, you are 100% correct.  These are all workarounds for functionality (allow trigger to post comments, allow trigger to run macro etc) that I would much rather have incorporated directly into ZenDesk without the need to make an API call.  As it stands now, I am using the HTTP Target calls as workarounds and the end result is working great – but small updates to a trigger by another admin could wreak havoc unfortunately.

    Hope some of this is helpful for you, if not…maybe for someone else!

    0
  • Jason Littrell

    @Steve I recommend signing up for the target failures log beta. It adds a tab to the API settings for you to monitor URL and HTTP targets. It's a manual process (no notifications, yet), but it is tremendously helpful to triage errors.

    To get around random failures for targets like yours that call back to Zendesk, I set up fallback automations that will run in the event that the first trigger or automation target fails. The gist of it is that the fallback automation will only run if a tag is not present, and that tag can only be added with a successful HTTP target call. 

    Here's how it works:

    First, you'll need a tag for when the target is first attempted (i.e. "target_initiated" in my example), and one for when it's successful (i.e. "target_successful"). You may need to make the tags more specific if you need fallbacks for different targets (e.g. "target_a_initiated", "target_b_initiated", etc.). Next, you would add this line whenever you call your HTTP target:

    "tags": ["{{ticket.tags | remove: 'target_initiated'}} target_successful"]

    This will remove the first tag (not exactly necessary, but I prefer to clean it up) and add the second tag when the HTTP target is successful. Finally, you just set up the automations like in the example below. The "Hours since update - is -" condition is very important. You can't save the automation without a set timeframe (or an action that nullifies a condition, which is what the HTTP target is supposed to do), and every time the target is attempted is considered an update. This way, a failed target call will not make any changes to the ticket, and the automation will pick up the ticket again the next hour.

    Trigger or Automation 1

    Conditions:

    <your normal conditions here>

    Ticket: Tags - Contains none of the following - target_initiated target_successful

    Actions:

    Ticket: Add tags - target_initiated

    Notifications: Notify target - <your HTTP target>

    JSON Body:

    {
    "ticket": {
    "tags": ["{{ticket.tags | remove: 'target_initiated'}} target_successful"],
    <the rest of your JSON here>
    }
    }

    Automation 2

    Conditions:

    Ticket: Hours since update - is - 1 (business or calendar, whichever you prefer)

    Ticket: Tags - Contains at least one of the following - target_initiated

    Ticket: Tags - Contains none of the following - target_successful

    Actions:

    Notifications: Notify target - <Your HTTP Target>

    JSON Body:

    {
    "ticket": {
    "tags": ["{{ticket.tags | remove: 'target_initiated'}} target_successful"],
    <the rest of your JSON here>
    }
    }

    ---

    As a final note, you'll want to be careful with this setup since it will retry the target indefinitely. If it fails too many times in a row, it will disable the target and send a notification to your Zendesk account owner. 

    0

Post is closed for comments.

Powered by Zendesk