Forums/Documentation/Agent Guide

Updating ticket properties from your inbox

Jake Holman
posted this on June 07, 2012 09:53

The mail API allows you to set properties on tickets by adding commands to the body of your email response to a Zendesk notification or to create a new ticket. Only agents can use the Mail API. If these commands are used by end-users, Zendesk will ignore them.

Here's an example of an agent reply to an email notification.

An agent can also create a new ticket by addressing a new email to the support email address of their Zendesk account and adding Mail API commands.

When Zendesk receives an email from an agent, we'll check to see if any commands are present at the top of the email, and execute the commands on the relevant ticket.
Note: You can only update an existing ticket by replying to an email notification for that ticket. In other words, you can't create a separate new email message and reference an already existing ticket. This is because Zendesk needs the ticket ID, which is contained in the Reply To email address (as shown in the graphic above).

Syntax

The Mail API simply scans the top of your email for the list of commands you want Zendesk to perform.

These commands follow this pattern:

#command value

If, for example, we wanted to set the status of a ticket, we can do so using this command:

#status solved

Each line should be separated by a new line. If we wanted to set the status and the assignee, for example, we can do:

#status solved


#assignee jake@zendesk.com

After this, you can simply put in your normal email content after your block of commands.

Short Syntax

For the more regularly used commands, we've added some quick and easy ways to use them, called short commands. These are usually one word commands that don't need a value. If they're supported by a particular command, they'll be highlighted below.

List of all Commands

Below is a list of all the supported commands you can add, one line by one line, in a response to a Zendesk email notification.

CommandDescription

#status

Valid values are open, pending and solved. #assignee must be set in order to set a ticket to Solved.

Short syntax:#open #pending #solved

#requester
 Sets the requester of the ticket. This can either be the users ID in your account, or simply their email address. If they don't already exist in your account, Zendesk will create it for you.

#group


Assigns the ticket to a group. Valid values are the name of the group or the ID of a group.
#assignee Assigns the ticket to an agent. Valid values are the email address of the assignee or the Zendesk ID of the assignee (obtained via e.g. a REST integration).
#priority


Sets the priority of the ticket. Valid values are low, normal, high and urgent. Note, in order to set a priority, you must also set a ticket type (see below)

Short syntax:#low #normal #high #urgent

#type

Valid values are incident, question, task and problem.

Short syntax:#incident #question #task #problem

#tags


Set any tag on the ticket, which can be separated by spaces or commas.

Note that this sets the tags, removing all previously set tags on that ticket.

#public

Sets if a comment update on a ticket is public. Only usable when updating a ticket.

The default value is true, meaning that anything else you put in the body of the email will be seen by the requester.

Short syntax:#note(meaning private comment)

Invalid commands

If any invalid commands, or values, are given to Zendesk then that command or value will be ignored by Zendesk.

An example showing all of the commands

This example shows all of the commands.

The above example will do the following to ticket #178:

  • Set the status to open
  • Set the group to “Support” and the assignee to the agent with “jake@zendesk.com” as their email address
  • Set the priority to “normal”
  • Set the type to “question”
  • Set the tags to “help” and “api”
  • Set the visibility of the comment to “private”
  • Add a new comment with “Hello world!” to the ticket, which combined with the above command will not be visible to the requester.
 

Comments

User photo
Kevin Hill
Crain

The short syntax is helpful. What are the chances of adding CC's using the API. I know that I can do it by adding the people to the actual CC field in the email, but the downside to this is that the people getting added get two e-mails -- my direct email reply (will all the other Mail API commands exposed, and which they might reply directly to breaking the chain) and the notification from Zendesk.

Would like to be able to do this:

#assignee joeschmo@fake.com

#cc janedoe@fake.com,jimbob@fake.com

June 26, 2012 09:24
User photo
John Gannon
thedigitrustgroup

This looks strikingly familiar to something we have implemented in our triggers and have been using for a few years (we call them commands also).  The only difference is we use 'z command' to issue a command instead of '#command xyz'.  Glad you guys are integrating this into the main system, it is very powerful for controlling tickets through the inbox!

That being said I do have 2 suggestions (from my experience using something like this for the past 2+ years):

1.  It would be nice to be able to create custom commands (similar to creating triggers).  The short syntax's are great (like #public or #note, awesome!), but it would be nice to define our own as well.  For instance one of our commands is 'z assign to me', or 'z assign to Rob', which is a lot nicer than having to write '#assignee rob.werjsas@xyzdomain.com'.  It makes using the commands feel a lot more natural (especially within email).  This can also be especially helpful for common repetitive tasks.  For instance, if what you gave as an example was something that our agents did repeatedly (several times a day), it would be much easier to define a custom command #doThis (which would perform all 7 steps) than have to continuously hammer out 7 lines of commands several times a day.

2.  The only other thing that would be nice is being able to set the delimiter/token to begin a command.  Like I said, we just use 'z command', which is a lot easier than trying to reach up to the # key five times per email (especially for something that is done often).  It flows a lot better and feels more natural when writing email (flows more like a sentence).  If that is a problem for someone maybe they could change to use a different token like 'zz' or something

July 11, 2012 16:07
User photo
Pete P
qatarairways

Does the curly bracket API format still work as well?

July 15, 2012 23:11
User photo
Jake Holman
Product Manager

@Pete: No, not in email. Only the documentation above will apply to email.

July 16, 2012 08:07
User photo
Patrick
nimbit

What is the format for creating a new ticket via email?

July 31, 2012 13:52
User photo
Jake Holman
Product Manager

@Patrick you should be able to just send in a new email to your support@ address with the same syntax as usual

July 31, 2012 14:09
User photo
Patrick
nimbit

Ok, this worked to create a new ticket. One question I have is, if I specify a requester email, will it automatically send that person an email about the ticket (even if the email is not currently a user)?

July 31, 2012 14:26
User photo
Jake Holman
Product Manager

@Patrick if Zendesk can't find anyone associated with an email you specify, Zendesk should create a new user automatically for you. It tries to be a little clever by taking anything before the @ in the email address and using that as the user's name.

July 31, 2012 14:52
User photo
Patrick
nimbit

Right, ok. But can Zendesk send the user an email when the ticket is created? I'm guessing not since it is assuming the user posted it, but in this case they didn't, we did on their behalf. I notice that as soon as our support team updates the ticket the user gets the notice though.

July 31, 2012 15:02
User photo
Jake Holman
Product Manager

@Patrick that's entirely dependent on the triggers and notifications you've set up under Manage > Triggers and Notification

If you're having trouble setting these up, do email support@zendesk.com and they'll be able to help you specifically within your account (and they're a bit faster than I am!).

July 31, 2012 16:27
User photo
Vitaly Pushkar

I send test email to support email address from my email account with this body:

#status open
#group Other
#type Question
#requester my_customer_mail@gmail.com

Hello there

 

And ticket is created in Zendesk panel but it's requester field is not 'my_customer_mail@gmail.com' as I specified in #requester -  it's my email address. The same with #group - it assigns to default 'Support' group but not to "Other" group (group "Other" is present in my Zendesk aacount)

August 01, 2012 03:43
User photo
Patrick
nimbit

Thank you. Do you think this method for creating tickets will continue to be supported vs. the REST API?

August 01, 2012 06:42
User photo
Aron Griffis

I tried updating a bunch of tickets simultaneously by putting them all in the To line, but it seems like only one of them worked.  Is there any way to do batch updates with the email interface?

August 01, 2012 14:49
User photo
Jake Holman
Product Manager

@Aron: Unfortunately that's not possible, sorry!

@Patrick, Vitaly: I'll look into what's going on with new tickets in regards to requesters and groups. We want similar behavior to the web UI for consistency, so this is a bug.

@Patrick: Support for this will certainly be continued - in fact this is the second version of the Mail API.

August 01, 2012 17:42
User photo
Bob Sherer
econet

@Jake, Vitaly: Isn't Vitaly's issue a matter of not including blank lines between each command?  That seems to be what the syntax requires.

August 09, 2012 08:29
User photo
David Goss
thackerays

Jake

2 little additions that I think would make a big difference:

#delete - same as "Delete ticket" in web app

#spam - same as "Mark as spam and suspend requester" in web app

August 22, 2012 05:03
User photo
Eugene Orr
crashplan

Hi,

Does this functionality work with light agents as well?  Thanks.

August 27, 2012 07:34
User photo
Jake Holman
Product Manager

@Eugene: There should be no reason it wouldn't, but Zendesk will ignore anything that light agents don't have permission to do (such as assigning to themselves, making a public comment, etc).

August 27, 2012 16:11
User photo
Roman R

I am trying to set tags this way but they are ignored. Do you have tags be already defined in previous tickets? Is there a way to create new tags this way?

August 28, 2012 01:11
User photo
Roman R

I think there's a bug in tag parsing. If any of the tags was not entered in the system before, the mail parser will discard all the other tags as well!

August 28, 2012 03:46
User photo
Jake Holman
Product Manager

@Roman: I'll create a ticket for you

August 28, 2012 09:04
User photo
Ben Schutz
fairfaxomg

Can we please have access to custom fields, since as you say, this should be similar to UI functionality. Perhaps it would be;

#custom_field_id value

or

#custom_field_name value

I think using only the id will make for easier implementation, but I can imagine other users getting a taste for using custom fields and wanting to use the name also. The trouble with the name is that you need to accommodate stuff like "Calls made to lead (where applicable)".

Similar to native fields, invalid values will be ignored.

September 06, 2012 16:31
User photo
Ben Schutz
fairfaxomg

Also cc would be good (without having to cc the actual email), ie,

cc user@zendesk.com

September 06, 2012 16:47
User photo
Lucas Alton
healthwise

I agree it would be an awesome feature to be able to change values for custom fields through the mail API. I have a custom field that I require to be set before the ticket can be closed, so at the moment my techs can't close tickets via email. I'm testing some work arounds but wanted to make known the desire to have this as a feature if possible.

September 06, 2012 22:15
User photo
Chris Mollan
Project C Beta Testers

Is there anyway a macro can be assigned when forwarding an email to zendesk?

September 27, 2012 03:56
User photo
Ryan Adams
kippnychr

Are there plans to add a due date command into the mix? I assume it could look something like

#due 10/05/12

Most of my ticket types are tasks, so having to go into the ticket to add a due date is an extra step at this point.

October 04, 2012 07:32
User photo
Ben Reyes
Zendesk

Updating Tickets via the Mail API by using the Subject Line Ticket No.

 

Just to clarify for people using the Mail API. It is not possible to update existing tickets with the Mail API when sending a 'fresh' email, only responses to Zendesk via email will execute the Mail API commands on existing tickets. The reason for this is because the API does not identify the ticket via the subject line of the email. The ticket is identified by the reply email formulated with a hash ID.

<Edit>

As @Ben Schutz mentioned below, you are able to use the mail API in new tickets from new or forwarded emails (e.g emailing support@[your-subdomain].zendesk.com with a ticket that does not currently have an ID or exists within Zendesk).

</Edit>

October 05, 2012 14:15
User photo
Jesse Burghiemer

^ If that is the case, this forum entry needs to be rewritten and the graphics changed. As it is, the diagrams are misleading: it looks as though you can update a ticket from a freshly composed e-mail, when you cannot. 

October 10, 2012 11:44
User photo
Ben Reyes
Zendesk

@Jesse Burghiemer: I know how frustrating this is as I too was initially confused by this. I will be pushing to update the article fully and making this clear within the content itself along with the screenshot. I've added in the comment above just as an intermediary step towards republishing this post. 

October 10, 2012 13:09
User photo
Ben Schutz
fairfaxomg

@Ben Reyes: I think your first comment raises some confusion. While this is in the context of updating existing tickets, "only responses to Zendesk via email will execute the Mail API commands" could be construed as a blanket statement suggesting that you can't use the mail API even when creating new tickets from new or forwarded emails, which you can.

Just in case anyone was confused.

October 10, 2012 16:30
User photo
Jonathan March
Enthought

@Ben Shutz: I didn't think that I was confused, but after reading your comment I definitely am. Could you (or BR) clarify, maybe with a link, how the process that you are describing would work? Thanks.

October 10, 2012 19:29
User photo
Andreas Larsen

I second the idea of supporting #delete to delete a ticket, and not requiring that anyone has to be assigned to it first.

October 14, 2012 22:05
User photo
Chris W. Parker

When will #duedate become available? I'm surprised this was omitted. Also, when it is implemented please make it possible to write in dates like "30 days" or "2 hours" and "next friday".

October 15, 2012 08:27
User photo
Jochsner

@Jake Holman @Ben Reyes:  Thanks for you detailed explanation of this feature.  This has been essential to our sales workflow to deliver services to customers expeditiously.  Do you have future plans to permit the use of custom ticket fields and their values in the Mail API commands?  This would go a long way.  As I type this I have a feeling your going to suggest  the use of macros and or triggers but I was hoping for something to set the custom field values at time of email response.  Thanks for all your hard work on Zendesk!  Oh and it's official, we're in love with Zendesk!  http://myamericommerce.com/blogs/shopping_cart_news/archive/2012/10...

December 06, 2012 16:40
User photo
Ben Reyes
Zendesk

@Jochsner: That is correct, unfortunately at the moment there is no way to access custom fields via the Mail API. I'll double check with the guys here if we are looking at extending the mail API further. Also Jochsner, I'm going to raise a ticket to discuss your use cases for the Mail API there may be another way around addressing what you want.

Thank you so much for the blog post and your kind words. It really does mean a lot to us here at Zendesk, it's what we all work hard for.

December 13, 2012 10:07
User photo
Ben Reyes
Zendesk

@Andreas Larsen and @Chris W. Parker: Thank you so much for your feedback. I will raise these suggestions with the guys here. Feel free to let us know about any suggestions or feedback regarding the Mail API here in this forum article. It's useful for us when we come to look at the functionality that's currently provided and how we could possibly improve it.

December 13, 2012 10:31
User photo
Jennifer Rowe
Zendesk

@Jochsner

Love the article, thanks! As Ben said, we really appreciate it! Happy to have you guys aboard! Your support site looks great. I hope to continue to see you around our forums too. There's a great community here that's growing all the time. Thanks again for the Zen-love!

December 14, 2012 10:50
User photo
Scott Boyce
gspretail

@Ben Reyes:  Bump for custom field support.

January 23, 2013 14:10
User photo
Johnny Yeip
competitorgroup

+1 for #duedate and custom field support

February 13, 2013 12:52
User photo
Craig Willis
hostanalyticsinc

It's unfortunate that the person sending the email on behalf of the requester can't add themselves to the cc list.  If they add other end-users they are added to the cc but not themselves.

Any reason why this is the case?

Craig

March 14, 2013 19:13
User photo
Brandon K.
Zendesk

Hey Craig,

I believe the reason for this is to prevent agents sending in an email on behalf of the requester being added as a CC every single time. We erred on the side of ease of submitting tickets so agents would not be afraid of forwarding their emails into Zendesk and then being blasted with notifications. Also, when your agent forwards in an email from a requester, our system reads it as coming from the end user and you cannot add mail API commands when you initially forward the email.

I hope this helps explain why this occurs.

March 15, 2013 11:21
User photo
Craig Willis
hostanalyticsinc

I can see that, in that case we just need the hashtag of #cc followed by a comma separated listed of people to be cc'd on the message and that will solve the problem.

Craig

March 15, 2013 12:19
User photo
Sebastian Nash
pebbleit

Just to let people know, #on-hold now works too.

March 19, 2013 04:50
User photo
Craig Willis
hostanalyticsinc

I also don't understand why this functionality is only available to agents, why not allow a end user to submit a case on behalf of another person.

Our use-case is that we have partners who need to submit tickets on their customers behalf.  If they could use these tags than that would be possible.

March 19, 2013 18:40
User photo
Brandon K.
Zendesk

Hey Craig,

I believe that the reason we did not allow end users to submit tickets on behalf of other requesters is because it opens up room for error if the email is misspelled and the possibility of abuse by opening multiple spam tickets for someone else. If you have end users that need to include other end users on a ticket, I would recommend having them create a ticket by sending in an email and having the other user CC'd on the email. This will allow the other user to receive copies of all the agent's responses, and then reply to comments themselves.

March 21, 2013 10:22
User photo
Ron Vichar
gtatech

I have some custom fields that are mandatory in order to solve a ticket.

Will this work with a field for example called #Time etc?  If the custom field has a space in the name how do I handle it i.e. #Service Type etc?

March 21, 2013 12:17
User photo
Ron Vichar
gtatech

Ooops my bad didn't see that a lot of people are requesting #CustomField support.  Guess it won't happen any time soon.

March 21, 2013 12:52
User photo
Bethany Nienhouse

Is there any way to set the notify customer option through the email API, without having to set it as a trigger? Something like this, perhaps:

 

#notify true

 

I'm sending out emails to hundreds of users at a time and don't want the assignee to have to go in and manually check the box. This would be a great feature. Let me know if there's a way to accomplish this, please. Thanks!

April 08, 2013 09:38
User photo
Brandon K.
Zendesk

Hey Bethany,

If you're asking about sending or preventing notifications by making the comment public or private the code for that is as follows:

#public will make the response public and will send out an email to your end user depending on your triggers

#note will make the response a private comment that only your agents can read.

Let me know if I misunderstood your question though!

April 19, 2013 14:29
User photo
Marissa M
pivotalconsulting

Having custom field commands will be key for us as we have required fields for end of the month reports for clients!

April 24, 2013 14:00
User photo
John Martin
jaspersoft

Populating custom field values via the Mail API would be huge for us ...

April 24, 2013 16:27
User photo
Brandon K.
Zendesk

@John & Marissa: Although you cannot directly change a custom field through the Mail API, you can add Tags which will allow you to fill out drop down custom fields. If you go to Manage > Ticket fields and edit the ticket field you want to be able to pick, you will be able to see the Tags that are associated with each different drop down option. If you then use the #Tags command you will be able to add a tag that will then in turn set the custom ticket field value. Be careful with this feature though, as the #Tags command is the set action, which will erase any tags you currently have on the ticket and place only the tags that you specify.

April 25, 2013 10:47
User photo
Chris W. Parker

Hi Brandon.

When should we expect to see #duedate coming?

April 25, 2013 10:49
User photo
Marissa M
pivotalconsulting

@Brandon: Thanks for the tip! However the field I'm specifically needing this for is a decimal field for time spent on a ticket (we use this as our IT help desk for service clients). I'm having issues with a few of my agents closing out tickets via the web portal due to the extra step of logging on. If I could train them to close out the ticket via these command prompts I think it would be a greater success. However entering those hours is a required field for closing out the ticket.

April 25, 2013 10:54
User photo
Jonathan March
Enthought

1. Correction: The privacy default of an emailed comment is the same as on the website, i.e. not necessarily public.

2. Request: It would be *very* handy to have a #take command.

Thanks!

April 30, 2013 16:44
User photo
Brandon K.
Zendesk

@Chris: I don't believe improving the Mail API is on our roadmap. I'll tell a PM that there is community support behind improving this feature, but I wouldn't expect any improvements to this any time soon.

@Marissa: The Mail API isn't designed to edit custom ticket fields. The only reason you can edit drop down fields is because of how each option is tied to a tag. I do not believe that there is a way that the Mail API could influence a free form custom field. If being able to fill this field out through the mail is critical and you do not need to be exactly precise, I might suggest that you break your possible time spent on the ticket into drop down fields. This is what we use internally and have each option as 1-5 minutes and so on up to 8 hours. This is the only way I can think of making this work without logging in.

@Jonathan: Yes, the email channel default is not necessarily set to public but it is not tied to the web portal behavior. You are able to set each one by going to Settings > Tickets. Although there is no #take command, you can assign tickets to yourself by using #assignee [your email].

April 30, 2013 18:42
User photo
Jonathan March
Enthought

Thanks for the reminder/correx regarding the source of default privacy settings. My main point however was to suggest that you correct the article, since not everyone will read every comment.

Yes, I did see the #assignee command. However I made the request for simple #take because the former is quite fragile. It's a long command word with double letters, and you know how often people mis-type email addresses! You clearly recognize the utility of alias commands, since you already have quite a few.

Since I'm on the topic, what would also be great would be to allow any unambiguous (among agents) substring of the email address (typically someone's first or last name).

Thanks!

April 30, 2013 19:34
User photo
Sonya Kathol
realtyexecutives

I can't get the #status solved and #solved to work via email. Changing to other statuses works okay. Is there a trick to this or some kind of setting I need to enable somewhere?

June 06, 2013 18:57
User photo
Jake Holman
Product Manager

@Sonya: It's possible the ticket you're trying to update does not meet the requirements for being solved.

A ticket can only be solved if and when it has an assignee. At the bottom of any email notifications you receive, you should be able to see who, if anyone, it's assigned to at the point of that notification being sent.

June 06, 2013 19:11
User photo
Sonya Kathol
realtyexecutives

I had created several test tickets and had made sure they all had an assignee. Even tried testing with two different assignees. 

June 06, 2013 20:14
User photo
Sonya Kathol
realtyexecutives

To clarify - just to make sure it wasn't a problem with one particular Agent, I didn't assign all of my test tickets to the same assignee. 

June 06, 2013 20:16
User photo
Sonya Kathol
realtyexecutives

Thanks Jake! There was a requirement the ticket wasn't meeting. We had a custom field that was required for a ticket to be marked as solved.

June 06, 2013 21:19
User photo
Jcruz
wharton

Hi, all.  One of our email administrators, when I brought up this as an option to update tickets, thought that it might be subject to ne'er-do-wells and nefarious parties by spoofing the incoming messages such that someone could manipulate tickets anonymously.  Is this protectable somehow?

June 17, 2013 11:11
User photo
Jake Holman
Product Manager

@Jcruz: Very good question. When updating tickets using the Mail API, only agents can perform the update.

You mention spoofing, which for those who are unaware, involves pretending to be sending from an email address you don't actually own. This is very easy to do - in fact I can pretend to be sending from any email address I choose, technically speaking.

There's various security in place to catch this (read up on SPF records as one example) but the easiest one to see is the reply-to email address. Whenever an agent replies to an email notification, the reply-to address contains a hashed key. You can actually see this in the example image in my original post, "help+id2SRB--Z461", which is used to verify the response.

When you respond to ticket notifications as an agent, we'll check to make sure that the hash in the "To" address matches what we saved when we sent you the notification. If it does, and the email address you're replying "From" is on your user profile, we'll consider it as an Agent update - in which case any of the Mail API keys you're using will be processed.

There's a number of other security checks we do - which I'm not going to deep dive on - which will either result in the mail being outright rejected at our mail server level (this is usually rare, we don't like dropping your inbound mails on the floor) or the update is suspended, which you can see in the suspended tickets queue.

Hope that answers your question.

June 17, 2013 11:39
User photo
Jcruz
wharton

Awesome, Jake, thanks!  I'm perennially impressed with Zendesk's thoughtfulness.  Keep up the great work!

June 17, 2013 11:47
User photo
Johannes Sidarta
revolutionitsupport

+1 #duedate

August 08, 2013 20:19
User photo
Laura D.
Zendesk

Thank you Johannes and Jcruz! We're glad you're enjoying Zendesk!

August 09, 2013 09:57
User photo
Marijn de Gids
televersal

To start another +1 for the #duedate

Another request: can we set the ticket form with the Mail API?

I did already find a workaround (usable for a lot of requests): send a specific custom tag in the email and pick that tag up in a trigger. (this could be a workaround for a lot of requests in this topic. Second tip: add a 'remove tag' in the trigger to remove the custom tag)

August 19, 2013 13:48
User photo
Luiz Teixeira
unexonline

Hi All,

In addition to the default commands for updating ticket properties via email, are there any plans to add commands for other ticket fields and, in particular, custom fields?

Thanks for your time! 

Luiz :)

September 10, 2013 10:01
User photo
Buck

Hi,

Please forgive my ignorance in advance :-P I'm able to understand bits and pieces of this discussion and at times felt like I had the answer I needed and then just the opposite. What I'm trying to figure out is whether I can use a form creation tool like Wufoo to create something like a "contact us" form and have it email our zendesk and in the process create a ticket for the requestor that we can then interact with via our zendesk. 

Nothing we've been able to do has allowed us to get the embedded zendesk form we're currently using as our "contact us" form to generate google analytics data so we can't track visitors who send in tickets. I've wasted an incredible amount of time trying to get GA to work with our support tab and our contact us form and I'm looking for a simpler solution. Being able to use any ol' form tool to email in a support ticket request would be a great solution. 

Is that what this thread is saying can be done? If not, can someone point me in the right direction? Thanks!!!

September 13, 2013 09:05
User photo
Bianca Llamas
Zendesk

@Buck,

I see that you have a ticket open in regards to your question. We will answer it there.

September 23, 2013 16:05
User photo
Patrick Reid
royalcupcoffee

When I forward a email from my inbox with the assignee# specified, it assigned the ticket, but it also made the agent the requester, vs the original user the email was from.

 

 

September 24, 2013 21:32
User photo
Dean
savethemoment

We send order dispatch emails to our customers from a separate application and I would like to also forward those emails in to our zendesk.  The requester needs to be the person we are sending to so it will either create a new customer record or the new ticket will be associated with an existing customer.

I realise we need to use #requester <customer emial> but is there any way to allow this to happen without using an agents email as the from address?  For example our order software will send the emails with the reply-to set to orders@mycompany.com but needs to be able to set the requester when a ticket is raised.  We don't want the reply-to to be agent@mycompany.com because we don't want replies to those emails to go to an agent and we don't want to waste an agent account by setting an agent up under orders@mycompany.com.

Is there another way to achieve this?

September 26, 2013 12:39
User photo
Trisha Patel
Zendesk

Hi Dean,

Another way to forward the email would be to enable email forwarding under settings > agents, once enabled, when your agents forward in an existing email to Zendesk, if you add the FWD: at the beginning of the subject line this will associate the email with the original requester rather than yourself. 

By forwarding this way or using ticket properties, the address must be an agent address in order for both to work I'm afraid. 

September 27, 2013 03:16
User photo
Dean
savethemoment

Thanks Trisha.  I managed to get round it in the end.  I've got our order software sending the dispatch email (with an agent as the reply-to) to support@mycompany.com rather than out to the customer.  I'm setting the #requester in those emails which is assigning it correctly to a customer in zendesk.  A trigger is then sending out the confirmation email to the customer and informing them of the ticket at the same time.

Its almost perfect apart from 2 small niggles....

1. Part of the incoming email contains a table of details of the customers order.  When its passed through a ticket and emailed back out to the customer by a trigger, the formatting is lost and looks messy.  From what I've read there doesn't appear to be any way round that.  Any suggestions?

2. The comment in the newly created ticket is labelled as though the customer entered it.  Is there any way to have that showing as an agent or the company name?

I have to say that I'm really loving the whole Zendesk experience so far!

Kind regards,

Dean (not Denis ;-) )

September 27, 2013 05:14
User photo
Oscar Tobar
Zendesk

Hey Dean! Glad you're enjoying Zendesk! 

1. Unfortunately, we don't have a workaround for the issue you are seeing with the table. 

2. This too, does not have a workaround as it is intentional behavior. Because the the email is forwarded on behalf of the customer, Zendesk will display this is being from them. 

October 02, 2013 11:33
User photo
Tj

So my company has many consultants.   Most would only be consulted on a ticket if they ever interact with a ticket at all.  I have cc'ed them in the past, but since they are not agents, they can not respond to the ticket as a note.   Does anyone know a way we can get a consultant's input without having the client see their internal notes?   I would like to keep a record of these communications that is in the same place as the ticket, but the communications would just confuse the customers of course.

October 02, 2013 17:20
User photo
Ingmar Zahorsky
Zendesk

Hi Tj,

Thanks for your question. While this is not possible directly on a ticket, you could use the linked ticket app and have a separate conversation with your consultant's on it. You can learn more about what this app can do and how to set it up here:
http://www.zendesk.com/apps/linked-ticket-app

 

October 06, 2013 04:29
User photo
Hanne Kosinowski
Skyscanner

Hi,

I was just trying to raise a ticket on behalf of someone else

with this in the message body:

#requester my_private_email@gmail.com

 

This is a test ticket opening it on behalf of someone else.

 

But the ticket is still assigned to the email address I sent the email from in the first place. Is there any update on this case? (It was raised on 1.8.2012 by Vitaly in this thread.)

October 16, 2013 07:34
User photo
Laura D.
Zendesk

Hi Hanne, 

I'm not sure Vitaly's issue was exactly the same (there aren't enough details to say for sure). I did some tests and when I did this as a regular agent this worked for me, the requester I named in the email became the requester.

That said, when I checked your account I saw that you're a light agent, meaning there are restrictions on what you can and cannot do with tickets.

Your syntax is right but when I tested this as a light agent in my test account, I had the same result you did: my email address was used as the requester, not the one I named in the body. That seems a bit odd to me. I'll create a separate ticket for you about this to see if we can get some clarification about this - look out for another email in a minute!

 

October 16, 2013 11:54
User photo
Hanne Kosinowski
Skyscanner

Hi Laura,

Thanks for getting back to me. I'll wait for the outcome of the ticket!

October 17, 2013 03:21
User photo
Jason

Is there a way to send an email to zendesk from gmail, that then goes to the client as opposed to emailing the client directly?

I want to know if there is another option besides having to login to zendesk directly. 

November 06, 2013 09:08
User photo
Ingmar Zahorsky
Zendesk

Hi Jason,

By using the mail API you could submit a ticket directly to your help desk from your agent account and set the ticket properties such as the requester. The notifications would be controlled depending on how you have configured your triggers. In the ticket received message you can certainly include the ticket email content. In that way, it appears like you are writing directly to the customer even though the ticket passes through Zendesk.

 

November 10, 2013 03:46
User photo
Richard Clifton
avidmobile

How do I find my Group number to use with the commands?

November 11, 2013 12:29
User photo
Laura D.
Zendesk

Hi Richard, 

You can find it in Settings: go to Admin > People > Groups (below search bar) > right click on the name of the group you're part of and select "copy address" > paste the address somewhere and you'll see the group ID towards the end of the URL. Let us know if you have more questions!

 

November 11, 2013 13:33
User photo
Barry Chertov

This isn't working for me. I added a #solved command on the bottom of my email reply (ticket was assigned to me) and the status wasn't changed. See screen shot at  http://www.waccobb.net/forums/waccobb/keep90days/2013-11-14_09-12-5...

November 14, 2013 10:24
User photo
Jake Holman
Product Manager

@Barry: You'll need to include your commands at the top of the email, not the bottom. That should solve your problem.

November 14, 2013 10:30
User photo
Jason

I'm not sure this is an answer to my question. I just don't know enough. I want to know HOW to do it. I submitted the syntax I used with a screenshot on the result. the result was that the client/requester received an email, however, it came from himself, not from me.

My test email:

**#status open**

**#requester mofootstlouis@gmail.com <mofootstlouis@gmail.com>*

**#assignee paul@clixfuel.com <paul@clixfuel.com> *

**#tags aaa**

**This email was sent directly to ZD from jason@ using SYNTAX and was assigned to P-K.** **by using a tag aaa it should send an email to the client too**

The [test] client received this message http://www.screencast.com/t/CYAtINfRQt6 but you can see it says it's from me, Jason Hylan, but in the body copy, it appears as if the test client John sent it to himself. I need this to appear as if it came from the assignee. *what are we doing wrong?* Thanks, -- Jason Hylan

November 15, 2013 13:40
User photo
Avi Warner
Zendesk

Hey Jason, in this case, this is as intended because when you forward an email from a customer to your Zendesk site, the ticket we create will be created using the comment that customer made, so our idea would be to represent in Zendesk, that they did actually make that comment. Can you tell us more about the workflow here? 

November 21, 2013 04:19
User photo
Jason Mcleod
Red Gate Software Ltd

+1 for #duedate

November 22, 2013 03:15
User photo
Marc Archer
zettics

I have customers opening tickets from both the help center and through email.

I value my customer's opinion on the priority and type of ticket (I want them to be able to indicate a ticket is urgent via the convenience of their mail client), but according to this article there is no way for a user to set priority and type in a ticket created by email.

Any plans to add this functionality (at least priority, type) for users creating tickets by email?

December 04, 2013 10:00
User photo
Emily
Zendesk

Hi Marcher, 

Email is tricky because the method for giving an email a high priority (i.e. flagging the email in your email account) doesn't translate to Zendesk.

One idea might be to establish separate support email addresses dependent on the urgency of the customer's request: i.e. outage@YOURCOMPANY.com vs support@YOURCOMPANY.com. You could then build a trigger to set the ticket priority to high on all tickets received at the outage@YOURCOMPANY.com email address.

Another idea would be to stick to your regular email address but build a trigger that says if comment text contains the word 'urgent,' set the ticket priority to high.

December 04, 2013 11:02
User photo
Marc Archer
zettics

Hi Emily,

I appreciate the suggestions, but a different email address per priority isn't feasible.

WIth just keywords searches in the comment text, you'd be forever guessing what humans write in the email, e.g. "not urgent" or "not so urgent" versus "urgent".

I guess I could ask all of my customers to use a notation such as the API does

#priority low|normal|high|urgent

#type Questions|Incidents|Problems|Tasks

and built trigger from that, but that was my point of asking for it to be built in!

December 04, 2013 18:39
User photo
Greg Fickel
iconstituent

I have seen a couple of peole ask about the ability to add custom_Fields but have not see a response. Forgive me if I am asking an answered question... But can we use this functionality for Custom Fields?

December 19, 2013 07:09
User photo
Laura D.
Zendesk

Hi Greg, 

The mail API doesn't support custom fields and I haven't heard anything about making changes to the Mail API in the immediate future. I can definitely see the usefulness of setting custom fields, though it would require some effort to figure out a naming system to be able to specify what field an agent wants updated. 

Hope this helps, let us know if you have more questions!

December 27, 2013 15:05
User photo
Renzo Fraschini

Hi,
I ma setting the que requester and other fields successfully using #requester custom@mail.com.
However I am failing on passing the requester name, this is what I tried so far: 
#requester "display name"  custom@mail.com
#requester "display name <custom@mail.com>"
#requester "display name"  <custom@mail.com>
Am I missing something or is this just not supported ?

Thanks in advance 

 

Renzo

January 01, 2014 14:27
User photo
Emily
Zendesk

Hi Renzo, 

The mail API is a method of updating tickets, not managing users. As such, it can update the email address of the end user (with the command "#requester custom@mail.com") but it cannot also send over a first and last name for the end-user. If you're creating this end-user for the first time using "#requester custom@mail.com," it will set the end-user's name to be "custom" or whatever precedes the @ symbol in their email address. You can then update it manually in the end-user profile. If the end-user already exists in your account and you use the "#requester custom@mail.com" command, it will match the requester to the name that already exists in your account. 

January 02, 2014 14:41
User photo
Clive Davidson

Is there a user friendly way to email updates to a ticket?
e.g. support+idticketnumber@XYZ.zendesk.com

Sometimes it can be difficult to track down an initial email from the ticket to reply to.

January 12, 2014 20:22
User photo
Klaus Gotthardt
Zendesk

Hello Clive,

In order for the mail API to function, you would need to reply to a Zendesk notification that relates to that ticket. Any notification from Zendesk with regards to that ticket will do.

Sending emails to an address as formatted above will not get added to the ticket in question.

January 19, 2014 03:06
User photo
Adam Bond
firstfleet

Can we ever expect a #cc command?  This would be very useful and would prevent the person who we want to CC getting duplicate emails.

February 12, 2014 07:49