We have multiple clients that will be sending an email to our client facing shared mailbox (email@example.com). We would like that email to deliver emails to various JIRA SM projects based on the domain of the sender but we are experiencing issues with that.
Our requirements are essentially this
1. one shared mailbox > multiple service projects distributed by the domain of the sender
2. JIRA SM will pull from Shared Mailbox and put it into the queue of the correct service project.
3. We want our shared mailbox to categorize the emails and we can probably do that through mail rules within Outlook.
What I have done so far:
1. I've created the shared mailbox, and folders within our inbox for our clients.
2. I have made service projects and I have their firstname.lastname@example.org
3. I have emails from email@example.com forward to firstname.lastname@example.org
So far this works, but the reporter name just says "email@example.com" instead of the service request submitter.
Thanks for taking the time, hope you can help me find a solution!
shared mailboxes don't work w/ JSM. there are a number of posts in the Community explaining this in more detail. Here is a recent one where Nic does a good job explaining. - Unable-to-add-Shared-Mailbox-as-custom-email-channel-for-project
the from address is going to be your firstname.lastname@example.org which will always be the reporter.
Even if you set up a dummy user email instead of a shared mailbox, there's another problem:
"one shared mailbox > multiple service projects distributed by the domain of the sender. JIRA SM will pull from Shared Mailbox and put it into the queue of the correct service project"
Not how it works. Each Service Project needs its own mailbox for its email channel.
Jack is correct, Jira Service Management cannot meet your requirements out of the box. You will need something like JEMH, or other plugin, that has the ability to parse email data. Even then, this configuration is unfriendly from an administration standpoint. The better solution is to use a single email account per project. Cheers!
Everything my fellow answerers mention is correct but I do see one possible option.
It does rely on having real mailbox and not a shared one tho.
If you use an IMAP(S) connection to you mailbox, you can choose a folder that you want to read instead of the Inbox of the mailbox.
Now if you set up some rules on the side of the mailbox to triage the mails when then enter to move them to specific folders automatically you can have each folder represent a different project.
That looks like a good idea. I'll give that option a try. I do have mail rules currently working in the mailbox, and as part of one of the rules I do have it forwarding to email@example.com opposed to added the mailbox to Jira. I'll see which works better.
So I looked through it and first thought I made a mistake and you needed an app (like JEMH or JETI) but when you go to your incoming mail configuration
There you can configure the mail server and mail handlers.
When you configure a mail server that is using IMAP(S) then you can set up a mail handler using the mail server where you can specify the folder to read (instead of the inbox)
(at the bottom)
So you can give that a try and see if it works for you :) I feel that right now that is the only solution if you only want to use a single mailbox/address
Some more info:
I found the approach of Dirk quite interesting as I was faced with a task like this in the past and we canceled it with "not doable" based on the information within this Suggestion which is finally in status "not being considered":
I mean to understand that the solution you gathered incorporates the "Mail Handler" (JSW/JC). If this works (happy if so) it would be great but on the other side this would mean I misunderstand a central rule all the time that was interpreted like:
So it means the Mail Handler route can be taken for a JSM project (what finally would erase JSDCLOUD-1518 from my radar)?
Wow, this is confusing :)
Hey @Daniel Ebers ,
I have to say I have not used the build in Mail Handlers too often. Due to the lack in flexibility of rules you can set and/or the layout you can do on the default notifications we usually move towards JETI (Email This Issue) and set up all our mail handlers there to centralize all the email management.
Now I'm aware that there is a difference between JSM and JSW Mail Handlers (at least on server) that from JIRA 7 and up there is a change that a user cannot create a ticket without a license (if I remember right) but that then details mainly JSW use cases.
On Cloud however I haven't found any such reference yet.
When you configure the mail handler (as I show in my above screenshot) you can select a folder of an IMAP enabled mailbox and on the next screen you can select any project (including JSM projects) so technically this should work.
Also other fields such as the default reporter for example cannot be set on the Email Request configuration in the project.
Whether this is all due to some development that got duplicated and these features don't really work together/an oversight I don't know.
I might have to do some testing whether we encounter the same license issue but it's not blocking me from setting it up so I would expect it to work (that's my personal philosophy, "if I can configure it it should work otherwise you should block me from setting it up like that")
I'd be happy to dive in to this further with you :)
And it seems it might just be the same on Cloud..
So even tho it is a JSM project the mail handler still rejects the email since the customer doesn't have a valid license (which it will never have).
When you define a default reporter it does work tho..
and your description contains the source email address:
[Created via e-mail received from: firstname.lastname@example.org>]
i'll see if the same behavior happens with the mail handlers from the app i normally use.
But it could be a workaround tho not yet perfect.
We often have questions from folks using Jira Service Management about the benefits to using Premium. Check out this video to learn how you can unlock even more value in our Premium plan. &nb...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events