Managing access to your service desk
Go to Project settings > Customer permissions to choose who can raise requests in your service desk and who your customers can share requests with.
On this page:
Choose who can raise requests
People need to be customers to raise requests in your service desk. You can let your team control who becomes a customer, or let customers create their own accounts in your service desk.
| Who can raise requests | Description |
|---|---|
| Customers who are added to the project | Your team adds customers to the project via the Customers page, or by raising requests on their behalf. |
| People with accounts on your Jira site are automatically added to the Customers list and can raise requests. | |
| Anyone can email the service desk or raise a request in the portal |
If this option is disabled, then your Jira administrator has not turned on public signup for service desks on this Jira site. Learn more When you choose this option, you have no control over who can create an account and raise requests. We strongly recommend that you use the Customers who have an account on this Jira site option instead, unless the requirement for a Jira account won’t work for your use case. |
Choose who customers can share requests with
You can allow customers to share requests with their organizations, anyone in the service desk, or people who aren't customers yet. The people customers share with become participants in the request. Request participants can comment on and share requests, and receive the same notifications from Jira Service Desk as the reporter. Learn more about request participants.
The following table describes the ways customers can share requests:
| Who customers can share with | Description |
|---|---|
| Other customers in their organization |
|
| Any customer, by typing an email address | Customers can share requests with other customers in their organization (like in the option above), and also:
|
| Any customer or organization, by searching in this project |
If your service desk uses user picker custom fields, such as the Approvers field, choose this setting to make sure customers can select users. |
Which settings are best for my team?
Not sure how to set up permissions for your team? Here are some suggestions for how to make customer permissions work for you:
| If you're like this | Who can raise requests | Who customers can share with |
|---|---|---|
| You have a service desk that handles contractors' leave requests. Only contractors can use the service desk, and you don't want non-contractors don't get confused about where to request leave. | Customers who are added to the project | Other customers in their organization |
| Your company has an IT service desk, and you want all employees to be able to create their own accounts and email requests. | Customers who have an account on this Jira site | Any customer or organization, by searching in this project |
| Your team provides software support for individuals. For example, if your company makes a free SAAS application that individuals use to manage finances, you can let your customers email bugs and questions to your service desk email channel. | Anyone can email the service desk or raise a request in the portal | Any customer, by typing an email address |
Security advice: Choosing who can raise requests
This is a security advice regarding the option Who can raise requests.
When allowing anyone to create and raise requests, we strongly recommend that you use a separate domain for your incoming email account and configure this account to filter against automatic emails by blocking the addresses with a local-part, such as “no-reply”, “support”, “servicedesk”, and so on.
Reason
Configuring your Jira Service Desk instance using an incoming email address with a domain at your company level can result in bad actors abusing the system to gain access to restricted services.
Example
For example, assume that your domain is http://mycompany.com, and you have set up a customer portal with an incoming email support@mycompany.com, allowing anyone to create and raise requests. Now, let’s say a bad actor is trying to gain access to teamsinspace.com for which your company already has an account (e.g. admin@mycompany.com).
If the bad actor creates a new ticket in your customer portal and adds no-reply@teamsinspace.com as a participant, they can now go to teamsinspace.com and open an account for support@mycompany.com and provide a team name including the ticket number. Since teamsinspace.com includes the team name in their confirmation emails (and other websites might include other details), such an email will be sent to your incoming email address in Jira Service Management, and added as a comment to the ticket. By clicking on the confirmation email, the bad actor could open an account on teamsinspace.com on behalf of your company.
Mitigating this issue
Using a separate domain or sub-domain dedicated for your customer portal will help prevent this as long as you make sure to not sign up to services using that domain. What’s more, adding filters against automatic emails (e.g. “no-reply”) at the incoming email account level will further help mitigate the issue because no-reply emails will be blocked.