Add end-user as CC via Trigger or Automation

Desired functionality: a way to automatically add a CC to tickets that match a certain condition.

Example: Trigger if Organization is "Acme Co" and Priority is more than Normal, then "Add CC" - specifying an end-user email address. This would allow the organization's primary contact stay in the loop about what their employees have requested.

Workaround: use a notify target "email" type to send emails to the person who needs to be CC'd.

I know you did and my reply does not seem to have posted for some reason. I read through your article and it looked great but in order to have access to the 'ticket form' function, I understand that you need ZenDesk Enterprise. I only have Team unfortunately.

We don't run the Enterprise edition of Zendesk. And even if we did then the solutions and workarounds presented here are much too complicated. Zendesk users need a simple solution for a common problem. Maybe we all have to say goodbye to Zendesk sooner or later.

I need this functionality badly! I am making email groups agents just to email certain groups and that's costing us. I need to be able to notify certain groups of certain actions the HD takes without having to pay for a non-existent agent.

This feature request and this post have been ACTIVE since 2009 and I assure you they are not completely ignoring our requests. They keep popping on from time to time to post updates and ask for information.

I think what Jake describes would address our need nicely. Many of our customers are large law firms. Most issues/requests from end-users are handled by the firm's in-house IT/Helpdesk/Admin but in many cases the end-users will come straight to us (our Zendesk setup is pretty open). In many cases, the firm wants to keep close tabs on the tickets their end-users open with us and they want to be able to comment if we need specific information that the end-user wouldn't know how or be able to gather themselves. The firm admins may also want to make sure their end-users aren't abusing the fact that our Zendesk is open and anybody at their firm can come straight to us. Some customers would also like these admins to be notified when new tickets are opened by end-users at the organization. Simply having the admin CC'ed on the tickets probably won't work for us, especially since the end-users are able to remove them. It would be better than nothing but still not what we would want to accomplish in the end. Is there another post related specifically to this sort of functionality that I can go vote/comment on? I notice the one linked below was just posted recently but was not sure if there was another one with more information:

I asked Zendesk Support about the mentioned comment by Jake Holman from 2015. Zendesk Support told me that he has left the company and the Zendesk developer team isn't working on that. They told me to use a workaround which is more or less unusable.

Our customers and our company are far away from being content with Zendesk's idleness.

Maybe it's best if any of us is asking Zendesk Support once a month about the progress on the possibility that (supervising) end users can comment tickets from their organization. It doesn't matter if a such a user is put CC or if he has the general right to comment. It's just important that it's possible in an automated way.

Even an upgrade from Team or Regular to Professional Plan doesn't solve the problem because Zendesk's workaround is a unusable.

The existence of the (unusable) workaround is at least something like a proof that Zendesk is aware of the problem although they deny that there is a problem or a missing function at all.

Nice job (not!) Zendesk! Pretty much ignoring your paying customers on a simple feature request that would be important to many of your customers! Granted, implementation under the hood may be more complicated than the feature from a user's perspective but come on: 7+ years with nothing to show for!!

Also, a fine example of poor communication: Zendesk should at least give feedback or just shoot this down rather than leaving the request/thread hanging for years!!

Having said that, we have been using the work-around noted in the thread (trigger + http(s) target) for a while already and seems to work OK'ish for our needs.

However, we've continued using the work-around for auto-CC (on organization's tickets). Probably should not hit a race condition when the CC field cannot be updated by a trigger anyway. In any case, user discretion is advised.

I was asked by Jessie Schultz, your Community Manager to post this here in the hopes that Zendesk PM can see it. It was originally written as a response for this thread, about using the self-target for API updates.

The responses from Zendesk in initial post:

'If a workflow is not possible using our native functionality, it's probably for a reason.'

and

'Consider re-evaluating what it is you want to accomplish. In most situations, you'll discover a simpler approach to solving a problem.'

Isn't really adequate, and feels a bit patronizing, to be honest. In our experience, the 'reason' is just that it's not been done on Zendesk's side, in some cases in spite of overwhelming and longstanding feedback from users requesting it (such as the request Tom linked to above). The 'simplest' way to solve the problem would be to just be able to select a given ticket property from a drop down in the trigger setup.

As a user of the self-target API workflow, I'd much prefer not having to use them. What would be better would be if Zendesk added more ticket properties as actions in triggers, or at least aimed for parity between things we can evaluate and things we could act on.There's a lot of feature requests that demonstrate a longstanding desire from users for things are often accomplished with these workflows.

Example 1. We would like to automatically change the recipient email on a ticket, so that our outbound replies come from a certain address if certain conditions are met, such as a VIP customer who contacts the regular support email. They should have their reply sent from a special VIP@ email, instead of the default one for the brand. Ticket Recipient cannot be set as an action in triggers, though it can be used as a condition in the trigger ( 'Ticket received at' ). If we can evaluate it as a condition, why can we not act on it?

1a. We'd also like to be able to CC their account manager or another end user when these users create tickets! ( a feature request that's 7 years old, 327 comments and 312 upvotes!)

Example 2. - Another common use case is field scrubbing when customers create followup tickets. Text, numeric and date fields can't be cleared by a trigger when a follow up ticket is created. We don't want or need the duplication of data into the new ticket, the issue might not be related. By prefilling a value, it bypasses any restrictions around required fields.

Customers often create a follow up for an old issue just because it's easier to reply to an email they received than try to go to the HC and fill out a new form.

There's no doubt this workflow of using a trigger to self update Zendesk via the API isn't a great one. Unless Zendesk implements the ability to triggers and automations to utilize *all* ticket properties as a condition and as an action, it's going to be a necessary evil that continues to irritate your admins, agents and users (and probably your support team). At the very least, if all the properties can't be done, they should be able to have parity between being a condition to evaluate and an actionable property.

We have a customer who routes their email through a support desk, which has an auto-responder. We can use the wording in the auto-response boilerplate to suppress notifications, but we can't suppress the CCs (which the customer uses because they have multiple actors) sent out by ZD when their auto-response is received. As a result, each round with this customer includes an immediate 10 autoresponses (after which their autoresponder stops responding).