Add end-user as CC via Trigger or Automation

Not planned

517 Comments

  • Jake Holman

    Thanks for the responses to Erin's post folks.

    I had one question I was hoping to get some feedback on. If we implement some sort of auto-complete field in Trigger/Automation actions to allow you to add CCs (and multiple CCs at that), is that not going to become a micro-management nightmare? Are you just going to end up with a huge long list of "CC these people" type of Triggers?

    1
  • CloudBringersSupport

    @Jake - Why would we wind up with more triggers than we already have. I may be speaking out of turn but I assume for most people 99% of the triggers they already have are exactly what we want, we can just add an additional item to existing triggers that say "CC person XYZ". I am not sure this needs to be an overly complicated addition to the product... we just don't want to type in emails manually each time into the CC. 

    In fact, why can't we just leave it as a textbox without autocomplete? Just allow us to type in the email manually into triggers. It will make the development time that much quicker. For some reason I get the feeling you guys are overthinking this a bit. 

    1
  • Joe Hettinger

    Looking at how the triggers are setup, it does appear as though we would have to create a trigger for each organization. However, a good naming convention and the triggers should be easy to manage. 

    IE AutoCC_CompanyX_custname

    AutoCC_CompanyY_custname

    AutoCC_CompanyZ_custname

     

    0
  • Thomas Whipps

    @Jake Holman - The way that we would implement the CC trigger is not so much to micromanage, but to allow better communication.  Right now I am able to let our Tech teachers view all tickets in their respective schools by using the "View all tickets in users org" option.  I need to take that one step further and allow them to comment on all tickets.  They don't need Agent permissions, but they need to be able to comment on the tickets.  Being able to auto-assign them to the CC slot would solve this problem without wasting time manually assigning them one ticket at a time.  This is the layout of the triggers that I have in place for each school.

    When a new ticket is created...
    and requester's tag is "school1"...
    assign agent "John Doe"...
    CC end-user "Jane Smith"... <<<THIS IS THE LINE WE NEED!!!>>>
    email agent "John Doe"...

    I don't even need the trigger to email the CC'd end-user.  I just need them added to the ticket to let them view and add comments.

    0
  • 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?

    3
  • Philippe Balogh

    Yes, Adam's proposal is highly appreciated. In our company a solution like that would end the discussion immediately about leaving Zendesk.

    1
  • Yannick Laurent

    Hi @Jake Holman,

    We use these 3 workaround rules for each customer who need this CC behaviour : Trigger + email_Target (first email sent to added CCs) + URL_Target (to *replace* CCs, and not add CCs because it's not API implemented, which may add another level of complexity).
    So we already use long trigger/target list, and we manage them using naming convention.
    This feature would simplify by 3 (and even more), the current micro-management. 

    0
  • Jake Holman

    @Andy: Well, everyone has different needs and to varying degrees. We like to really dig into a problem and understand that problem's complexities inside out. We don't want to implement a solution to a problem we don't understand.

    As for a text field, afraid that's not gonna fly. The current implementation (Add Agent CCs) is already a lookup, and using a text field would actually end up complicating the implementation. We need to tie the action to an actual user record.

    @Thomas: Ah, that's interesting. Are your customers only using email, they don't sign into help center to manage requests from there? 

    I ask only because what you describe is actually available today. See in particular step 4. Please do come back and let me know if/what doesn't work out for your use case there.

    @Adam: Yes, I'm glad you brought this up. This is actually a solution we've been thinking about for a while. I'm going to elaborate more on that in another comment, so please bear with me.

    @Yannick: Thank you for reminding me about that workaround, I had not considered that when thinking about micro management. You're totally right.

    Thank you once again for all the feedback guys, keep it coming. In the meantime, I'm going to be coming back with a short explanation on the history of this request and how we intend to deal with it.

    0
  • CloudBringersSupport

    @Jake - If you want to tie it to the actual user record then the implementation is even simpler. We've done this for several months through an API trick but we are afraid to disclose it because you guys have been so negative towards this topic in the past we were afraid you'd close the hole and screw our implementation. 

    The way we solved this is by having a custom field called "Direct Report Email Address". Whomever needs to be notified can be linked right inside of the customer record. Then when we make a trigger we can simply use 1 trigger for all customers because it pulls the email from the "Direct Report Email" custom field. If you have situations where more than one person needs to be notified you can always add more custom fields, or simply add some kind of delimiter like ";" or "," and parse them.

    Again, it strikes me as funny that you guys "don't want to implement a solution to a problem you don't understand". This thread is over 5 years old and has hundreds of comments... the problem seems quite apparent. 

    1
  • Thomas Whipps

    @Jake Holman - That solution would work for my case in particular if I could select "...And add comments" for individual end-users.  I don't want or need everyone in the org to be able to see and comment on all tickets.

    If I could do this on a per user basis, then the "add end-user to CC" trigger would be unneeded for us.

    2
  • Brian Gibson

    My needs:

    Ability to add an end-user cc via trigger.  for me, this doesnt need to be an open text field, it would be nice, not necessary.  Instead, i just need to be able to select an email from my customer base. 

    I need to be able to automatically add a cc from the customer base, when certain terms are met such as: Org 1 wants their CTO to be cc'd on any tickets that are urgent priority.

    Example:

    When Organization = Org1

    &

    Priority > high

    do:

    add cc - important end-user of company

     

    This is a huge request from our customer base

     

    1
  • Zach Johnson

    Why does this have to be tied to a user? A lot of the notifications that need to be sent out are just so other individuals are aware of the requests that have been opened. If a request needs to be escalated why would you need to have someone senior or executive level be a user, when all they need is awareness of the situation.

    What I find puzzling is the fact that an Agent is able to add a CC with no problems (again if they are an existing user), but an end user can't when creating or updating requests? Fine, make everyone within a organization an end user including executive team or senior management. Why not add a field so when they are creating tickets to include those other individuals?

    Hope I'm missing something simple, but Jake how many times are you CC'ed on e-mails (not requests) just so you are aware of a product development or need to provide feedback? Our customers need the same level of functionality when requests are made.

    I've watched this ticket for a long time now and the workarounds that are having to be done in order to fulfill this request seem to be very labor intensive to manage and setup for specific client scenarios.

    1
  • CloudBringersSupport

    I'm 100% on board with Zach's comments. I am extremely confused why as an agent I can manually add a CC to anyone without issue, yet the same functionality cannot be added via a trigger. There are many cases where I want to send an email to someone who will never under any circumstances qualify as a user. 

    1
  • Joe Hettinger

    Do we have an ETA on when this feature will be added?

    0
  • Erin the mentor

    Thanks for the continued feedback, all. There's no ETA at this time, but we are looking at these use cases as we begin to plan for 2016.

    0
  • Jake Holman

    So I wanted to go back to Adam Pepper's comment earlier in the thread, as I'd promised to do earlier.

    > "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."

    This is actually ideally how we'd like to deal with the use cases here. There are two particular high level changes we'd like to make:

    1. Introduce some sort of hierarchy into Organization memberships. Today in Zendesk the memberships are flat. There are no concept of departments, teams nor managers of either. We'd like to change that, so they almost have a "Role" of sorts within the Organization in Zendesk. This will allow us to treat those roles as very different, offering them further functionality and permissions beyond what they have today
    2. Then, to complement this, we adjust the request management experience. A "Manager" role within an Organization could, for example, be able to see an overview of all tickets within the Organization, add and remove members in the Organization (so long as their identities match the Organization domain mapping) and, of course, subscribe to receiving updates about all ticket activity within their Organization

    This adds another dimension to self service. Of course, we'd need to give agents some tools to help in that too, such as signing a manager up for receiving ticket updates.

    Somewhat related side-note: requesters will soon be able to have more control over which non-Zendesk agents are CCd on their requests, as well as being able to define that during request submission.

    I notice there's a few votes on Adam's comment, so I'm very keen to hear feedback on this - particularly if you feel that doesn't even come close to addressing your need.

    0
  • Taras Savchuk

    Jake,

    What about addressing possibility to automaticaly CC end user on some _subset_ of organization's tickets? For example, 3 our simple live cases:

    1. End user wants to be CC'ed on all tickets from live persons but not from monitoring (yes, we push notifications from Zabbix directly to Zendesk).
    2. End user wants to be CC'ed on each organization's ticket form live person or monitoring with urgency > "High".
    3. End user wants to be CC'ed on each organization's ticket with some sort of SLA violation (i.e. response time or something other).

    I think you're overthinking yourself. Just add posibility to CC end user in triggers/automations and we are done and happy. Some sort of hierarchy in organizations is absolutely another feature not related to CCing direcly. I can say more - the feature (auto CC end user) is needed only in 1/10th of customers maximum, so don't be afraid of high load or great volume of new triggers. And don't treat us (your customers), please, as stupid, don't try to sell us completely different feature as solution for long standing CC problem.

    Sorry for some sharp words and with fading hope for understanding.

    P.S. Re-read the topic title -

    Add end-user as CC via Trigger or Automation

     - this is all we need.

    2
  • James Porter

    Hi Jake,

    We have some large organisations that have multiple products from our group of companies.  Currently we use Brands to categorise our product lines but it would be useful to be able to set up a structure beneath the Organisation to include departments/teams with managers.  I must be honest and say that Taras is correct however - this seems like a solution to a different problem.  Ultimately all we need right now is the ability to add cc's via trigger or automation so that we can loop in a person when needed.  If I could tag a group of people as 'managers' within an Org and then CC the managers group when conditions are met then so much the better... but I could live without that for now.  Your customers are pretty much telling you what they need, why over complicate?

     

    1
  • Adam Pepper

    Hi Jake

    As our requirement to be able to automatically add a person/people as CCs to tickets for an organisation is for so many organisations, we're looking for a way to achieve this that a) avoids the need to configure triggers for each organisation and b) is transparent to agents - so the functionality you outlined would work well for us.

    Being also transparent to certain end users would be a bonus, and appreciated by many of our clients. However it wouldn't be appropriate for just any end user to remove who is cc'd on their ticket, and our agents would need to be able to easily see when this has happened (and by whom).

    Apologies to those who really need the trigger functionality extending for hijacking this thread. Fingers crossed for a solution/solutions that provide the functionality we need very soon.

    1
  • Steve Dark

    Just to add a massive +1 to this thread.  We are being asked by many of our customers that one person needs to be notified of all tickets at the organisation.  The fact that we are not able to offer this seems strange to our customers and makes them question our competence.

    I look forward to any update that addresses the issue of adding an End-User, or an email address as a CC via a Trigger.

    1
  • Lou Gallo

    You can set it by any userid via the API tho.  So you can set it to an end user in the ticket form and via the API but not as a trigger... seems like you need to simplify your field lookup.. Easy fix I think..

    https://developer.zendesk.com/rest_api/docs/core/triggers

    Just wrote a py script to do it. 

    0
  • Simon van de Westerlo

    Hi all, take a look at https://support.zendesk.com/hc/en-us/community/posts/205750118-CC-Customer-On-All-Organisation-Requests , seems there's a solution for this issue.

     

    1
  • Gareth Bristow

    +1 on this. I'm surprised this very basic functionality isn't in the software already. My only guess is that it was identified as a potential revenue leak scenario and everything we've been reading about "trying to understand" our use cases is just a nice way of saying it will never be implemented because it could allow companies to circumvent licence purchases.

    However there are legitimate use cases which do not involve revenue leak. I am using the Target workaround, but it is not ideal.

    0
  • Taras Savchuk

    Erin Boyle November 04, 2015 22:02 wrote:

    Thanks for the continued feedback, all. There's no ETA at this time, but we are looking at these use cases as we begin to plan for 2016.

     

    Today we have February5, 2016...

    Are you going to making any "plan" for 2016 and address CC problem in it? ))

    1
  • Mary Kay Soto

    +1 on this. Having this functionality would make life so much easier!! 

    0
  • AdamPearce

    We would also like to see this included. I have raised this under support case 1455364. I mention in that case that I do not see why you can manually CC anybody on a ticket, including an end user but you cannot do this automatically. Surely something that can be done manually, can be done automatically?

    0
  • Erin the mentor

    Hi all,

    Quick update. While there's still no movement on this in terms of actual work, we are narrowing in on a proposed solution we think would work nicely for this problem. It would allow you to automatically notify certain individuals without forcing you to create different triggers (or automations) for each end-user that has special notification requirements.

    There's still a lot of internal discussion that needs to happen before we start such a project, but I'll pop back here every once in awhile to keep you informed of any progress.

    Best,
    Erin

    0
  • Jeff Guyette

    Thanks Erin!

    At this point, any update from you on this long-sought-after feature is good news... and even better to know that your team is finally making some headway on identifying a method to move forward with.

    We know it has been a tough nut to crack, and appreciate the effort.  I look forward to hearing more about this as it becomes available.

    0
  • Taras Savchuk

    Erin, thanks!

    "A lot of discussion", "such a project", "any progress"... bla-bla-bla...

    ((((((

     

    0
  • Mike

    So after 6 years all that has happened is

    "While there's still no movement on this in terms of actual work, we are narrowing in on a proposed solution we think would work nicely for this problem."

    I'm lost for words ...

     

     

     

    1

Please sign in to leave a comment.

Powered by Zendesk