Dear Atlassian Community
we’re using Jira Service Desk with five different projects.
Actually the projects are not reachable by mail. Means that requests via Mail are disabled.
As we are working with Jira service desk since some months, we’d like to set up the reachability of all our Jira Service Desk projects via Mail.
Important for us is
So the problem is that we can only link one custom email address to each project. That means it is not possible to communicate one single email address. Or is there an other workaround to solve this?
Thank you and best regards
Irina
land in sicht
How should your Servicedesk know in which Projekt the issue should be created?
I never tested if you could control this by permissions.
But there are some add ons which could check the subject or content of an e-mail and create an issue in one of a few projects. (for example E mail this issue)
I think we will solve it with one new Jira Service Desk project which we'll only use for all email requests (with our custom email address).
Nevertheless thanks for your response!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
email creation has a 1:1 relationship - email-address:project, so every project where you want to enable email request must have a unique email.
you can certainly create your own custom email address, e.g. proj1@mycompany.com, proj2@mycompany.com, etc.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
When we create different mailaddress for each project, unfortunately it is not possible to communicate only one mailadress to all our customers (independently which Jira Service Desk Project they are using). Perhaps we can solve it with one new Jira Service Desk project which we can be used for all email requests.
Nevertheless thanks for your response!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Feature request for the same please vote & watch for visibility: https://jira.atlassian.com/browse/JSDCLOUD-11071
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
This is a workaround that will satisfy your requirement, not a solution.
Note:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thank you very much for sharing this workaround. Given the current limitations, i really appreciate you taking the time to explain this approach in detail.
I tested this setup using a common project with automation to clone tickets to the appropriate target project based on the sender domain, and so far it seems to work as expected in our testing.
Before moving forward, we’d really appreciate your opinion based on your experience. Are there any risks or limitations we should be aware of if we proceed with this approach in a production environment? In particular, we’re curious if you’ve seen any issues related to email reply threading, notifications, SLAs, reporting, or long-term maintainability.
Thanks again for the helpful suggestion
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
IMO, this isn't an ideal solution or at least it is far from risk free. It will take regular if not constant monitoring to ensure your customer communication and hence CSAT remains high.
@Phuong Do , what exactly are your requirements? Why not have a single project with multiple organizations for each company? You can pair that with dedicated development projects where needed with linked issues to actually track the work. The key for me is maintaining that personal connection between the Agent and the Customer on the original ticket. Automation can be used for some of this for sure but with care.
Ultimately the right solution for you depends on your exact situation and requirements.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks for your perspective, really appreciate it.
To clarify our requirements, we need to maintain two separate service projects because we are supporting two different clients with different agents and also expects a clear separation in reporting and daily operations, which is why a single service project seems not feasible for us.
We did consider using Organizations within one project, but this does not fully address our concern. The Organization field mainly helps with grouping customers and access control, and agents would still need to manually identify and handle requests based on that field. With different agent groups supporting different clients, this could seem cause confusion and increase the risk of misrouting or incorrect handling.
And yes, from the workaround, we do acknowledge the very dependency of automation on this
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.