• 0

    Unfortunately the first "comment" will always be public when you are creating a ticket via the API.

    There's only one exception where you decide to take a forum topic and escalate it as a ticket where private comments are in the background and any public comments on that "ticket" will appear as a response on the forum topic.

  • 0

    So would the work around be to simply create the ticket as usual using the API with a null value for the description, then add a comment to the ticket that is set to private.

  • 0

    Dustin, what's your use case?  Are you trying to create a ticket and not notify the requester?  More information would be helpful here to determine the best course for you.  

  • 0

    Here is the basic idea.

    There are certain events that happen automatically in our back end that require a customer followup. The followup itself happens only after our support rep reviews the customers account, makes notes, then determines the course of action for the followup; a phone call to the customer, or an email. We want this all to be managed through zendesk.

    The only hiccup I've found to making this work, is that the ticket description is always public. I was hoping to put the basis for the followup in a private comment... I'm worried so much about the request being notified...

  • 0

    I too require this functionality quite desperately!

    My staff may create a ticket with a comment not intended for public consumption and then later decide to email the customer.  The first comment will appear in the email thread unless they specifically go and change the initial comment to private later on.  This could be very dangerous if my staff have put passwords or other sensitive information in the initial comment.

    I find the initial comment on a new ticket to be quite bizarre.  The initial creation of the ticket doesn't (and can't) generate an email to the customer as far as I can see, but IS public and there is no way to alter either as far as I can tell.  Being as we purely use Zendesk for email at present neither of these functions are helpful.  Sometimes my staff want the initial comment to go to the end user and that is currently impossible, and sometimes they will want the initial comment to be entirely private and that is currently impossible too!

    When creating a new ticket the same buttons that you have once a ticket is already created should be present so that you can choose whether the initial comment is to be private, and whether or not it will be sent to the customer.



  • 0

    Hi Paul,

    I created a ticket for you so someone from our support team can help you! You should hear from them soon! Thanks!

  • 0

    The way tickets on Zendesk are set up is meant to encourage engagement with the customer. When you set a 'Requestor' and a 'Description' you are supposed to be describing the problem/question/etc and who has it. When you set the description yourself it is expected that the requester already relayed the description to you. The requester doesn't need to see your summary of what they told you, they just need to see your responses (this can be modified, I'll get to that later).

    I understand why it is confusing, because the description appears to be just another comment, but it is not. The customer must be able to see a description of the request that they supposedly made for Zendesk to remain a help tool.

    Here are some potential workarounds:

    Here at Zendesk when we find ourselves in that kind of situation we add a simple description first, it can even be just the subject line or an expansion of what is there. Then, we create a private comment with the details that should be to obscured from the end-user/CC's.

    If you are having more extensive internal discussions in tickets you may consider setting yourself as the requester so that end-users don't see anything. Then, if you later decide to notify the end-user, you can create a new ticket with the end-user as the requester and just link in the existing internal ticket in a private comment.

    You could modify the "Notify requestor of received request" trigger to contain a condition like "Tags contains none of the following: no_notification", so that if you add no_notification as a tag to a ticket the end-user will not receive the "Request Received" notification. If they log in online they will still be able to see the ticket though. I also wanted to add that you can include the ticket description in the initial email by modifying the 'Notify requester of received request' Trigger under 'Manage' > 'Triggers and mail notifications'. Just add the ((ticket.description)) placeholder, replacing ('s with {'s, to the text of the email action. You could potentially build two separate 'Notify requester of received request' triggers, one to include the ticket description and one that does not. You have complete control over when those emails go out and what they contain with triggers. Let me know if you'd like some help setting up or modifying those triggers; I'm subscribed to this thread and more than happy to help.

    I hope my explanation helps you understand why it is the way it is. That said, we do also understand that there are some legitimate use-cases for making the description private and are looking into adding it as a feature as we move forward.

  • 0

    Thanks Joseph.  That makes sense, I would definitely like to see as an additional feature.


    I have prepped my staff so that they understand the situation in the mean time.


    Thank you for taking the time to discuss it with me.



  • 0

    Though I see this is the logical way to proceed when a user has access to zendesk, it may not make sense while using the API.

    In our specific case (having in mind the need for bi-directional information) the API has to retrie app related information (such as user name and user ID), injecting it in the ticket fields.

    If the first ticket has to carry said information and it is visible to the end-user, the content may be modified, thus creating a security breach between our apps and our zendesk.

    Now if there was a way to set the first comment as private (like in mail's API "#public false" statement), it would be great.

    Any workaround for this?



  • 0

    Hi Pedro

    This would currently be more of a feature request. I can confirm that there is not a way to make an initial comment private. In terms of a work around, it is possible pass information in custom fields and to make those fields not visible to the end user. So, in other words, the work around would be to would be to move the content out of the description/ comment area and into custom fields and pass the information that way.

  • 0

    This request has been up during the last years with a lot of comments here


    I understand the part of "encouraging" but in our company we want to have the possibility of starting with private comments and later engage the customer.

  • 0

    Hey, everyone - 

    We've been looking into the issue of first comment private for some time, but haven't made any forward movement on it. That may change very shortly, but we have a few specific questions. Rather than add more comments here, we're looking to have a conversation with some customers who are still actively looking for functionality like this. If you'd like to participate and speak to me about this feature, please sign up here.

  • 0

    Thanks, we've closed the form after receiving overwhelming support.

  • 0

    For anyone who has not already signed up, we've opened a beta for this feature. We're planning to add users in batches, but it will be an open beta.


Please sign in to leave a comment.