We need the same Possibilities to configure the E-Mail Handler in Servicedesk, like in Jira itself. At the moment we got several Problems regarding the Adding of Comments and the exclusion of signatures

EDIT
Atlassian support has informed me that the primary JIRA Incoming Mail configuration for advanced mail loop protection functions with JSD mail handlers even though those handlers are not listed in that space.

This means the 15 minute interval and the Threshold and whitelist configurations should affect JSD mail handler behaviour as well.

We would also like to be able to configure some of the JSD email settings, most pressing for us at the moment is the Bulk email limits and exceptions as this could cause emails from our larger organisation clients to be ignored if multiple people are raising or communicating on issues, via email, at a similar time - resulting in disrupted communications.

Some of the other settings that the generic JIRA email handler has would also be nice to have (such as defining a "folder" other than "inbox" to check).

@Lingbo Lu

Thank you for reaching out. I would like to chat with you about our current problem.
However, if I click on the link you've send me, I'm just directed to the original ticket.

@Ruud Stechweji Interested to hear if Lingbo offered any insight to your issue by email?

Currently experiencing exactly what you described back in July.
We are encountering more and more situations where customer interactions are being "lost" because JSD lacks the ability to display users that were CC'd on emails sent to the service desk.

I have added my vote as a JIRA cloud user.

Here is the paradigm employed by our existing HelpDesk.

"External cc" is a separate field. This field gets populated when an incoming email creates an issue (which std Jira can do) and is thereafter used and updated:

• when mail gets sent to Reporter, "External cc" also gets a copy
• if a new email arrives and creates a comment, any additions / removals to the cc list are taken into account.

I.e. it works just like Outlook...which is what people expect. It avoids any bad complications like suddenly creating additional users etc etc and is simple incremental addition to the existing functionality. (of course, if someone on cc is already a registered user, then can be added as a Watcher instead).

What would be even nicer is if a cc populated other users, non internal. For example, if I have client company A. And my point of contact submits a ticket and cc's their boss. It would be nice if the CC of the boss ( who can also submit tickets into JSD ) could actually see responses instead of think we completely ignored the request. I would think it would populate "request participants". Which I can do manually but is quite inconvenient.

I up voted this issue, too.
If our customers send us an request through e-mail, service desk ignores the CC colleagues.
But it is important that CC colleagues aren't ignored to send information to them, too.

hmora@excentia.es, is your service desk open access? i.e. do you allow public signup on your service desk?

ruud1, I'm keen to chat with you about the problem. I'm going to send you an email.

Cheers,
Lingbo from JIRA Service Desk

I have added my vote as a JIRA cloud user.

We are using Zendesk for our customer service desk, but we are planning to change to JIRA Servicedesk to be able to:

• connect our Confluence knowledge base
• transfer Servicedesk project issues directly to the development

We are still in testing phase and I'm a little bit disappointed that the e-mail handling is quite basic.
If our client sends us an e-mail with 2 colleagues in CC, these colleagues are completely ignored by JIRA Servicedesk.

The client chose to add them to CC for a reason, so in our opinion they should always be updated as well.

How much votes do this issue need to be developed? Will it be available in JIRA Cloud?

I have added my vote.

If a user can create an issue through "Customer Portal"... Why he/she can't create an issue throug mail? May I need to add all my customer portal users to "jira-servicedesk-users" to allow them create issues via email account? Thanks!

@luca - i don't think your statement is accurate. the document you refer to states that it can only triage on content or keywords in the summary or the description. @gareth asked about triaging on the specific email address (or alias) that the email was sent to.

it seems that the "to" address is not available - and the "from" address is used to set the Reporter.

i also have a HUGE need to do some basic automation on the "To" field - this seems like such a basic requirement.

I am just curious - what are the concern of having SD mail handler to "add contacts in the cc list automatically as watcher or participants" not yet possible in comparison to the standard (non SD) mail handler? Say from the consumption of user license point of view?

Thanks @Luca,
What would the JQL expression be testing for? The original recipient email address is in the email headers but not in the body of the email.

@gareth Service Desk can already do this using automations since the latest update - see https://confluence.atlassian.com/servicedeskcloud/automating-your-service-desk-732528900.html

A requirement we have is to automatically triage issues sent by email. I'm sure it would be a fairly common requirement.
For example, we might have 3 separate mailboxes for getting help from the Finance department (Payroll, Account Receivable and Account Payable)
Emails from all three mailboxes should create a new issue in the Finance Service Desk with the Issue Type being determined from the original mailbox the email was sent to.
This would be very easy to do using the "catch email address" of the generic mail handler but nearly impossible and/or unmanageable with the current Service Desk mail handler.
Please add catch email address to the Service Desk mail handler.

Also a critical issue with the Service Desk mail handler. If you move an issue from a SD project to a non-SD project, and respond to any email that came from SD, the mail will not process and be disregarded by Jira. This has caused a MAJOR rift in workflow for us. I currently have a ticket in with Jira, but they are saying this is by design.

To repeat:
1.) Submit an issue to a Service Desk project. You should receive an Issue Created email from SD.
2.) Move the issue to a non-SD project.
3.) Respond to the original SD Issue Created email you receive.

It should add a comment onto that issue. It does not. You should see an error in the SD processing log that states: "The Service Desk you are trying to view does not exist." This result does not occur with the standard Jira mail handler.

I would just like the ability to add CC's, and extra "to:"'s to my participants list.
Cheers

I would really like to use JSD to manage support tickets in one place, but as many stated above it lacks some basic functionality and it is not ready for production use without it. Maybe we will use our plain old RT as some kind of email proxy for JSD, but it is as silly as it sounds.

Atlassian,

I am struggling to understand how to operate your service desk without requiring our customers to stuff around endlessly trying to manipulate what could only be described as a sub-standard service desk offering by yourselves. Clearly there is significant oversight on your behalf when first embarking upon this venture. In this day and age, email is paramount and people spend endless amounts of time constructing useless messages which they believe are more important than anything/anyone. As such, to convey the constructed message across they choose to cc the world in and therefore place an expectation upon the business is work for that any message outbound include all recipients of the original message. Given the limitation of your current mail handler, this can not be achieved. This needs to change immediately. How hard can it be to get the email handler to capture a few email addresses and place them into a text box? Alternatively, why can't the original email be captured as an attachment to the raised issue. This would allow the service desk staff to view the original email and copy and paste the cc'd addresses into a custom text box.
Please advise what is the status of this issue? From what I have read, there are many users wanting to use this product however are not seeing any benefit given this situation and are sourcing alternatives.

This feature is critical to implementation of JSD across our enterprise. All stakeholders need to be kept updated on the issue to support our customers, both internal and external.

We definitely need the ability to capture and respond to all incoming mail recipients. Keeping all parties in the loop to the issue that was submitted is critical to our business and customers.

Look at this product: https://www.smartertools.com/smartertrack/online-help-desk.html

This is the functionality that is required in JSD!!! It's practically an email client. I am an actual user of it and love it. I had high hopes for JSD but the email handling, pardon me, but totally sucks .

I ended splitting my help desk staff and my development staff. It's not the desired platform, but works very well.

Teresa Dickerson is right, we have faced this issue also a lot of times, which results in doing a lot of the time administrative corrections in the Jira tickets, hence lost time...

The lack of CC handling is a major oversight and renders this product useless for 75% of our requests. Due to the lack of CC handling, Jira Service Desk creates multiple tickets for the same issue whenever a CC replies. Each ticket is then associated with a single person and only has their individual comment, making it impossible to effectively support via JSD.

1. The CC field should add the additional parties as 'requested participants' (this allows them to leave the ticket/conversation within the customer portal, if they no longer want to be included)
2. If they don't have an account, it should handle the CC the same as the TO field and create their account
3. The mail handler should recognize replies with the same summary and add them as comments to the ticket, rather than creating multiple requests for a single issue

I've been unable to find a workaround for this, I'm interested to hear how anyone is using the email feature in it's current state.

Can we get an update, Atlassian?

"The Jira mail handlers were able to create tickets from emails sent to any address as long as they were in the inbox. However, Service Desk doesn't seem to do this. Instead Service Desk seems to only raise tickets from emails that have the configured email address in the TO field."

This is a major oversight too. But CC'ed users as watchers is the most important missing feature (again, readily available in JIRA vanilla, already available in Spiceworks et al).

I want to be able to remove attachments (e.g. signature jpgs, follow us on facebook jpgs and a like).

still no answers for this feature?

In our company many requests are authorized if the responsible person is added in the CC in the mail request. As CC field is discarded by JSD email handler we cannot check this out in the JSD issue.

Really need the cc watcher option which is already available in the non-service-desk mail hander.

Not exactly. What I want is to be able to define a set of rules so I can parse the contents of an email and populate specific fields with the relevant data. I also want to define a set of rules so that any email sent to Jira Service Desk that has an existing issue key in its subject is added to that issue as a comment. As things stand, our Agents have to populate the resulting issue manually by copying data from the body of the email by hand.

Sample email: all fields are of the format "$field: $value".

From: Ronnie Dobbs <ronnie.dobbs@brutalizin.com>
Sent: Wednesday, June 17, 2015 12:23 PM
Subject: ESCL L3 : SR # GOOG02152525 / 441780I / Interociter / SEV: 2 - Severe Restriction / Globochem
Body:

Case Details
SR Number: GOOG02152525
Case Title: Expansion issue and new Replication Group in error
Severity: 2 - Severe Restriction
Escalation Priority: 2
Answer Required By: 17-Jun-2015 16:10
Reproducible?: Yes
GSC Contact: Ronnie Dobbs - AMER

Customer Details
Site ID: 441780I
Customer: Globochem
Country: New Freeland

Product Details
Model: Interociter
Sub-Model: 3.5.1.4855
Hypervisor: VMWare
Chassis: 2
Interociter Version #: 3.5.1.4855
External Vendor:
Vendor Case #: n/a

Summary:
Please see an attached screen shot.

The "reset password" email generated by the system displays the following text, which is not helpful.

I saw the best minds of my generation destroyed by madness, starving hysterical naked, dragging themselves through the negro streets at dawn looking for an angry fix, angelheaded hipsters burning for the ancient heavenly connection to the starry dynamo in the machinery of night, who poverty and tatters and hollow-eyed and high sat up smoking in the supernatural darkness of cold-water flats floating across the tops of cities contemplating jazz, who bared their brains to Heaven under the El and saw Mohammedan angels staggering on tenement roofs illuminated, who passed through universities with radiant cool eyes hallucinating Arkansas and Blake-light tragedy among the scholars of war, who were expelled from the academies for crazy & publishing obscene odes on the windows of the skull, who cowered in unshaven rooms in underwear, burning their money in wastebaskets and listening to the Terror through the wall, who got busted in their pubic beards returning through Laredo with a belt of marijuana for New York, who ate fire in paint hotels or drank turpentine in Paradise Alley, death, or purgatoried their torsos night after night

Steps to Replicate:
1. Navigate to the front page
2. Click the "Reset your password" link
3. Enter your email address
4. When it arrives, open the "reset password" email

Expected Result:
The mail will include a link that will reset the user's password.

Actual Result:
The mail has no clickable links. Instead, the mail displays an excerpt from Allen Ginsberg's "Howl".

In this example, a mail handler could parse the values using ": " as a delimiter. The resulting issue would be populated thusly:

It strikes me that while a large number of the commenters on this issue are just wanting proper cc handling, this is not actually what the original issue description is talking about (or if so, very indirectly).

I have created a more focused Suggestion for this here: https://jira.atlassian.com/browse/JSD-1593

In case it helps out anyone else who is watching this issue, I tried out the Email This Issue Plugin, and it didn't work for us at all. See the currently-unresolved problem discussed here: https://metainf.atlassian.net/browse/JETI-768 as well as the problem described here: https://metainf.atlassian.net/browse/JETI-769

What we ended up doing instead was installing the Apache James mail server, and writing a couple Mailets that run inside of James. One examines the sender on incoming e-mails, queries a JIRA web service to see if they are a recognized user, and if they are not, it changes the sender to a default JIRA user. It saves the original sender's e-mail address at the end of the subject line. The second examines all mail sent back out from JIRA to that default user, grabs the original sender back out of the subject line, and changes the recipient to the original user. This way, comments that are made on the issue in JIRA still make their way back out to the original user, even if they don't have an account.

Of course, I would prefer that JIRA Service Desk just fix this problem, and I could throw our Mailets out. But if anyone is interested in trying out our solution, let me know, and I'll open-source the project.

It would be great to have it automatically mark anyone who is CC'd in the email as a watcher for the ticket created by the email. We are currently switching over from Solarwinds Web Help Desk and their CC feature is used quite heavily by us so that multiple people who are CC'd on an email will still get updates when we update a ticket. The "Watcher" ability is great, but it's completely impractical to have to manually add watchers for every ticket.

Would really like the add CC's as watchers for service desk to, as well as other configuration options, like extra email addresses on the email handler to pick up redirected emails etc.

Tim,
Thanks so much for the pointer. I contacted Tibor about the Email This Issue plugin and its upcoming Service Desk integration, and he confirmed that it will fix this problem. He estimated a release by the end of next week. Hope this helps someone else watching this issue. I will try it out once it's available and post an update about whether or not it worked.

Also for us the lack of automatic creation of the Cc'ed address is a showstopper, we are working for international customers, and we never know upfront who they will include in the Cc. So setting up the users upfront is impossible. Also setting up users upfront should be possible directly from within Jira Servicedesk Customers section. Now you can only invite, but there should also be an option to just create a customer without invite, but that is a separate issue not related to this request.

Does anyone have any suggestions on any kind of work-around?

It looks like the Email this issue Plugin gets an update http://www.meta-inf.hu/wiki/x/kwC6AQ

This is currently only the 23rd most voted on issue for this project, but almost all of the issues with more votes look like a LOT of work compared to this one, especially just something as simple as setting up a default user that unrecognized e-mail addresses come from. Please consider prioritizing even just that piece of this issue above some of those larger efforts if possible.

Wow, yeah, how did this enormous gap in functionality get overlooked? I can't believe that e-mails from users that don't have accounts just seem to get silently ignored. Does anyone have any suggestions on any kind of work-around? I would be happy to work on a patch for this, but it appears the JIRA Service Desk license doesn't include access to the source?

The lack of support for cc'd users staying on the request may be a deal breaker for us, though we'd much prefer to stick with Jira and Service Desk.

We just purchased this software and were hoping to scale it to all departments but this is a huge gap in functionality. We've gone through 4 other service desk products and this functionality has always existed out of box.

Strongly agree with this issue. If someone is CC'd on an incoming request they should stay on that request, it is a basic functionality that almost any service desk utilizies. We need this added!

Being able to set the Jira mail handler "default user" would be very handy as well.

Currently, the only way to allow everyone to create and issue via email is to open Service Desk registration.
In our use case, we'd like to catch all mail sent to the service desk email address (defaulting the reporter to a default user), but not open the Service Desk portals to publc registration

I should also add that support agents should be able to add new emails to be notified (whether colloborators or external email addresses) when replying to or resolving issues.

Would it be possible to achieve this by adding watchers to the issues? I suppose, you can't add watchers as external email addresses at the moment?

Voting for this issue. I have the same use case as Brandon.

How the features "add cc as watchers" and "create user" and "notify user" work ?

Cc watchers if he doesn't have a Customer account, the system create the account for him

Thanks Joseph, I've done a basic test and can confirm it works.

tersvaer, the fix has been deployed in On Demand version 2.2-OD-04 and hosted version 2.1.1. All emails in your support inbox will be processed. https://jira.atlassian.com/browse/JSD-827

Strongly agree with this ticket and CC feature !!

I also vote for adding CC'd users as watchers

As stated above, the ability to automatically add CC'd users as watchers would be very useful.

I would like to be able to configure the JIRA Mail handler.
I'm using the Service desk cloud product.

I need to be able to capture all other emails (not the service desk email) from the Cc field and add them as "watcher" of the created ticket.

This is generally the intention of the sender: for instance, if I send an email to the helpdesk and Cc someone else, I expect this person to receive the answer too. If I don't want this behaviour, I just put them into Bcc or I tell them in person.

I am cutting traditional Jira projects over into being Service Desk projects.

The Jira mail handlers were able to create tickets from emails sent to any address as long as they were in the inbox. However, Service Desk doesn't seem to do this. Instead Service Desk seems to only raise tickets from emails that have the configured email address in the TO field.

We use email aliases which appears to be now broken in Service Desk.

For example,
Primary email could be...

abcd@xxx.com.au

which has fictional aliases...

aliases1@xxx.com.au
aliases2@xxx.com.au

The mail box user name however would be the account ID like, for example:

mb344447aw

When sending individual emails to all three addresses, I only get one ticket raised. From my example that would be the primary email (i.e. the one configured in the Service Desk mail handler).

So either we need a way to add additional Service Desk mail handlers or, be able to add alias email addresses to the existing mail handler.

Strongly agree with this ticket. The Service Desk Mail Handler really needs more functionality/configurability. For example, it should allow capturing CC email addresses and adding those into the Service Desk ticket as "watchers". Later responses on that ticket should be CC'd to them.

Similarly, it would be ideal if other Mail Handler plug-ins are able to work with Service Desk. Examples include JIRA Email This Issue (JETI) and JIRA Enterprise Mail Handler (JEMH).