Add end-user as CC via Trigger or Automation

452 Kommentare

  • Offizieller Kommentar
    Kristen Mirenda

    UPDATED 4/11/2018

    Hello again -- I wanted to give an update about the other project I mentioned which was going to provide a foundation for this functionality. It's just been released to a limited beta. There would still be work to do to leverage that feature for this one, but this moves us a huge step forward. The beta is literally days old so after it's had a chance to run for a while, we'll come back and update again.

    UPDATED 9/25/2017

    Sorry we've been so silent, but we don't want to repeat the past mistake of posting as "planned" something that's still in research mode. But I can tell you that a project is underway right now to lay the groundwork for this feature. Depending on how it goes, we hope that we'll be clearing the way for 2018.

    Please bear in mind that this is not a guarantee, and that our priorities may shift between now and then.

    --

    Hi everyone -- there's been a ton of conversation around this proposed feature and I understand it's of critical interest to many. Folks are asking why it was never built and it's an excellent question. I wish I had an excellent answer but honestly, I don't know exactly why, as Jake and Erin have moved on.

    Asking around for folks who were involved with conversations over the years, I was able to find out that they couldn't easily surmount the problem of scale presented by the end-users data set.

    However, I hear you all very clearly that it's important that we continue to look at this. I've initiated a few discussions already and I'll continue to investigate our options and whether anything has changed regarding technical constraints. In the meantime, to avoid confusion, I'm officially removing the "Planned" label.

  • Erin Boyle

    Hi all,

    I know I posted here a couple months back, and then went radio silent on you. That was certainly not my intention, and I apologize for the lack of transparency.

    I want to start off this post by summarizing the 4 main use cases we're seeing throughout this entire thread:

    1. Certain organizations always want a person or group of people to be notified of tickets

    2. Certain organizations always want a group of people to be notified of all tickets, but want certain individuals to be notified of a subset of tickets

    3. Certain users always ask for a person or group of people to be cc'd on all of their tickets

    4. Account managers or other semi-dedicated internal agents want to be notified of all tickets for a specific organization

    We believe use case #1 on this list will be addressed by the planned feature (no, really) Deepa mentioned earlier, which is organization subscriptions. This seems like it's the largest use case, and it is on the roadmap.

    Use cases #2 & #3 we do not have a solution for yet. I know the request here is to provide a way of adding these email addresses in directly to triggers & automations, but I'd like to think about the right solution here. We need to think about the manageability of these types of lists, possible implications on the volume of triggers, etc.

    As for use case #4, this really fits quite nicely with our vision for Light Agents. These types of people (account managers, technical account managers, etc) typically do need access to view and participate in tickets. Aside from the fact that Light Agents are only available on the Enterprise plan, is there a way in which Light Agents don't meet the need here?

    Let's focus in on use cases #2 and #3 in order to have a productive conversation and spend energy on the use cases that aren't already being addressed by a roadmap feature. It's clear that there is a real need here that's impacting both your agents' productivity and, in some cases, your credibility with your customers.

    Some questions:

    • How often do you find that organizations have multiple sets of people that need to be notified in different cases? (e.g. A, B, and C want to be notified of only High or Urgent tickets, and D only wants to be notified of Urgent tickets)
    • How often do you find that individual users (not at an organizational level) expect to have automatic CC's?
    • In all of these cases, how often do these lists of people change? Do agents need to easily change or add to these lists?

    Thanks for your continued feedback and participation in these discussions. We really do want to understand the problems you're facing, and look forward to working with you all on this.

    Best,
    Erin

    5
  • Adam Pepper

    As I previously commented:

    Our requirement isn't for an End User to be CC'd on a trigger or automation - but something a little simpler. For an Organisation, we need to be able to nominate one or many Users to be automatically CC'd on every ticket linked to that organisation. We would only need to be able to choose from users linked to that organisation. Agents or the CC'd user would be able to remove them as a CC on a per-ticket basis.

    We have dozens of customers who are organisations who want us to automatically CC a particular person on every ticket creation (such as their project manager on new implementations, or a central or third-party IT contact), plus many who would appreciate it if we offered it, and we definitely don't want to be managing individual triggers to deal with this.

    Something that would work well for us would be an additional option for Users on an organisation. So not just

    • User can view own tickets only
    • User can view all org tickets

    but also

    • User CC'd on all org tickets

    which we could set for zero, one or many users for each organisation. I think it would take the trigger maintenance issue out of the equation. Ideally, the user would be added to the ticket as a CC with the organisation, and could be removed by the agent on a case by case basis if they felt it was not appropriate.

    Is this feasible? Would it work for other use cases mentioned here?

    5
  • Matthew Pietz

    Just make it a text box where you can type part of a name and it will autocomplete, agents and users.

    4
  • Mike

    We really need this feature too!

    It can't be that difficult to to give us a blank field rather than a drop down so that we can just type in the email address that needs to be added to the CC list?

    Since the functionality is already there to add the email address of an agent to the CC field then it is also there for any email address to be added, just change the field from a drop down to an entry field and we would all be happy.

     

    4
  • Kristen Vales

    +1 New to Zendesk but really need this.  This would help us tremendously for our end users who are managing multiple organizations.  

    4
  • AdamFronteras

    Can we have an idea of when this will be, onm the roadmap does not really help much in planning - 12 weeks, 12months,  12 years! 

    thanks

    Adam

    4
  • Dan Bristol

    Yup, 

    Pretty disappointing!  

    They also just closed a ticket on me regarding this issue without even letting me know.  I inquired about the status, and then didn't even hear back, so I went to look at the ticket, and it was closed.  I had to open a new one again, and still haven't heard anything on that one.  

    They were supposed to refer it to services to see about coding a small piece of the API / url solution to remove a user cc.  

    Maybe everyone should just open tickets, so someone else in the organization notices?  

    4
  • CloudBringersSupport

    @Erin,

    It's strange you are asking for use cases... the fact of the matter is that it doesn't matter. This is a feature everyone is clamoring for (just look at the number of comments in this thread). If you want to push people to paying more for the feature, which you currently do by requiring us to upgrade our plan and move to a plan which allows for unlimited light agents, which in and of itself is confusing. There are actually not technical hurdles in play, since we can manually add addresses to the CC any time we want. The functionality is already there. If you can make a case why it consumes additional resources on your end, fine. Offer it as an additional paid feature for $5-$10 a month per agent. I doubt anyone would care, especially because for many of us this is literally making or breaking our business.

    If you still require use cases, here is a legitimate one we run into daily:

    We oversee IT for several retail chains. Direct support requests always come from in store management. District management wants to be notified about all tickets opening, and all tickets closing. They also like to be able to add input when necessary, especially when they know information that the store manager wouldn't. Also, their corporate IT staff wants to know how often certain requests are being made, so they would also like to be notified as tickets are opened. 

    A second example would be in many of the office environments we oversee. Every individual needs to manage their own support per their "cubicle" or individual computer station. Because many of our customers are on an hourly rate the office manager likes to know how many tickets, and of what type, are being opened on a daily basis. This helps office managers determine whether it's cheaper to keep fixing dippy problems like clearing browser cache, or bring us in for a 1 hour training course on computer basics.

    The use cases will be nearly limitless. Can you please detail us the hesitation in adding this feature both currently and in the past? 

    4
  • Jessica Spurling

    Why is this still not possible? 

    We could use this functionality. There are multiple threads in this community asking for this functionality. For years. Several years.

    How hard can it be to change the field from a drop-down to just a text field? Just let us type in the email address if you can't figure out a better way to do it. Even if it was a text field with no validation whatsoever it would be better than not letting us have any way to do this.

    -jessica

    4
  • Petri Rossi

    Wow, unbelievable!

    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.

    4
  • Dan Ross

    Hi Zendesk, 

    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.

    4
  • At least some explanation from Zendesk why this feature hasnt yet been implemented would be appreciated. 

    4
  • Avi Warner

    If anyone is interested, I'm working on an app that will allow you to add email addresses as CCs via a trigger. Hoping to have a prototype working in a couple weeks. If you'd like to beta test, let me know.  

    4
  • Hans Weihe

    How on earth can it take Zendesk so long, to implement this obvious and very simpel feature. 5 years?

    3
  • Taras Savchuk

    Hey, Zendesk, are you alive? :(

    This thread is open for 5 long years... (((((((((

    3
  • Christopher Thomas

    I find it truly astonishing how many times I read a post where hundreds of people are all looking for the same functionality and yet it is rarely added. I really don't see what would be so difficult in allowing someone to type in an email address to have it add to the cc list. For a customer driven product you do a very poor job of listening to your customers.

    3
  • Marco Eegdeman

    5 years waiting  for a text field instead of a dropdownlist....???????

    Zendesk shame on you.

    3
  • Dan Bristol

    Please, 

    Can I request that the ability to remove CCs also be included when this is implemented in 6 years from now?  

    That way we will not have to start this decade long process over again.  

    3
  • Christopher Thomas

    It wouldn't circumvent paying for an agent. They still wouldn't have access in any real functional way any more than manually adding a CC. You can get around this lack of user support that Zendesk seems to enjoy by locking down the light agents - add your end users into the light agent role (free and unlimited) and allow them to only see their tickets - now you can create a trigger based on the light agent. That being said, I find article after article after article with people upon people asking for the same things. Printing help articles, adding triggers, etc. with very rarely anyone actually solving a problem that involves a lack of features. We asked about the screencast function when we saw that current company was shutting down and were assured that they were actively pursuing a replacement. Is there a replacement? Of course not! If we ran our tech support and customer service in this fashion we would be in deep trouble and people would be losing their jobs! Personally, we've been looking for an alternative.

     

    3
  • Joe

    Adding CC's who are not agents via a trigger would be helpful to our company as well. We are considering leaving ZD because this feature does not exist and the poor formatting of the new portal vs the old portal. The new portal wastes so much space compared to the old portal.

    3
  • Brian Gibson

    My organization needs this as well, high priority item.  An update from Zendesk would be great

    3
  • AdamPearce

    They are hoping that we will all just give up!

    3
  • Ron McClung

    It's ridiculous that my agents can CC any end-user but I can not add them automatically.  This needs to be changed.

    3
  • Jordan Kerr

    Would also like to see this and be able to CC external users.

    3
  • Sean Heisler

    If the issue is the size of the end users' table, a quick fix would be a checkbox on the user record along the lines of "Allow Triggers" - which then puts that user just like the list of agents in any trigger menu. 

    For many of these use cases, feels like anyone who works with enterprise clients, seem like there is a "key customer contact" for accounts want to be in the loop on all, or certain types of, activity

    +1

    3
  • Matthew Foval

    Adding triggers does not work for us. In our organization, if a Middle School student submits a help desk ticket, we want to automatically CC one of the students' designated teachers. The reason we need to do that is NOT because we just want the teacher to see that "xyz" was occurring, but instead, we actually need the teacher to be able to correspond and to provide updates for us on the ticket. Without that ability it means not only that we have to add the CC ourselves, but also that we have to manually lookup each students' designated teacher before we can even add the CC manually. So there are two extra steps for us without this ability.

     

    Not done and very dusty feature request here.

    3
  • Jeff Guyette

    Thanks, Kristin!  I appreciate the update and really look forward to additional updates from you regarding your teams progress on this as you resume your research into it.

    Many others within this thread have mentioned that they suspected the reason Zendesk wasn't pursuing this feature might have to do with the use of the "Light agent" functionality. However, I don't see the two as directly linked. Having been subscribed to this thread for many years now, I've read the descriptions of desired use by countless administrators, and when taking those into consideration, along with our own needs, I think it's safe to say that the ability to auto-CC an end-user on an individual ticket is not really the same thing as providing someone Light Agent access.  

    Having been subscribed to this thread for many years now, I've read the descriptions of desired use by countless administrators, and when taking those into consideration, along with our own needs, I think it's safe to say that the ability to auto-CC an end-user on an individual ticket is not really the same thing as providing someone Light Agent access.  

    I sincerely hope that your team will come up with a simple and effective solution which will allow those many of us seeking this feature the ability to do what we are looking for, without the clunky workarounds, and without any intrusion to your agent licensing either.  

    Thanks again!

    3
  • Avi Warner

    @Bruno, it's a one time cost that goes to buying me a coffee every once in a while :)

    @Jeff / @Steve / @Greg thanks for the shoutout, glad the app is working for you.

    3
  • Toan

    This would be a very useful feature.  The workaround of notifying a target by email has a flaw: if that target replies to a given ticket, it'll open a new ticket each time instead of allowing them to add a comment as it would for the requester or an agent.

    2

Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.

Powered by Zendesk