We're in the process of making a private service desk for internal issues, where certain personelle and some external users can submit issues to this service desk via direct email.
We do not want this service desk to be visible when users log in to the support portal unless they've been specifically added to this service desk.
For example.. we allow public signup for our main helpdesk in a project called ISSUES. We also allow public signup for our internal helpdesk called II (for Internal Issues).
If someone is added to the system via ISSUES, they should *not* be allowed to see the Internal Issues support desk.
This is my test login to a user that was automatically added by emailing to our ISSUES customer channel. They should not have access to the Internal Issues service desk.
you make projects visable to customers by controlling the customer list for the project. only share the email channel for the project with the customers you want. each project can have its own channel. So in the case of internal project I would create an Organization and add the internal employees to the organization. Note the Organization piece is optional and you could just add the employees to the project w/o placing in org.
Thanks for the input, but I'm looking for something a bit different.
Yes, visibility is controlled by the customer list, I get that. But when customers are automatically added via emailing a customer channel, they are automatically given access to all customer channels.
I do not want this automatic part to happen for all customer channels, just for the channel that they emailed.
I also don't want to manually add emails to the customer channels, because they could come from a variety of sources especially for internal issues, such as from automatically generated from addresses from system monitoring.
So the ideal solution for me, is that when people email firstname.lastname@example.org, they are given access to *only* the issues helpdesk. When people email email@example.com, they are *only* given access to firstname.lastname@example.org.
Right now, when someone has an automatic email account generated via emailing email@example.com, they *also* automatically gain access to the internal helpdesk. This is a big blocker for our purposes.
Mark, thanks for the info. I haven't hit this issue and it has been awhile since i set up my project and new users coming on so I need to investigate when i have a moment. That said, all of my JSD projects are internal and use a unique custom email, e.g. IT@company.com, firstname.lastname@example.org, email@example.com. I have public sign up on and these emails are shared with the desired 'customers' so that when they send in a request they are added. If memory serves they do not see the other projects. But again, i need to research this to refresh my knowledge.
In the meantime I expect other will chime in here! :-)
In "Customer Permissions">"Who can raise requests", check "Anyone can email the service desk or raise a request on this portal" if your desk is opened to external people or "Customers who have an account on this JIRA site" if your project is internal. If all your employees have access to JIRA and / or Confluence, they will be able to raise issues - no need to have access to JIRA Service Desk.
That's what I did when I faced the same use case as you: create desks for my internal team + create desks for my customers.
The main issue is I think the 'anyone can email the service desk or raise a request on this portal'.
I want two *different* service desks to have completely independent users, and both be in the 'anyone can email this' category.
If someone emails service desk A and is added as a user, they should not be automaticlly added to service desk B
They are classifying this as a new feature instead of a bug :(
In my view this is most certainly a bug and should be treated as such. It's a massive problem to have people given access to all service desks when emailing into one.
Here's the issue:
...be more productive while being fun to use at the same time. For some, getting started can be a bit intimidating. This is especially true if Jira Service Desk is your first exposure to Atlassian...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG