Restrict the creation of tickets of your Jira Service desk Cloud by Domain

[#1]

Hello Community!

During the time I've been supporting Jira Service Desk Cloud, one of the most requested functionalities I saw in Cloud is the ability to restrict the customer portal or the creation of tickets to customers with a specific domain, not allowing any other customers with undesired/unknown domains to do it.

In fact, we have some feature requests to implement this option with a considering amount of votes and watchers:

Include Domain Level Restrictions for Service Desk Public Signup 

User(s)/Group(s)/Roles security on creating certain "Request Types" 

Unfortunately, there are only two options to restrict the customer portal in Jira Service Desk Cloud today:

1. Allow only the customers manually added to Service desk projects to access the portal
2. Allow Anyone to self sign-up in your Jira portal, as long as they have the link of your site

We understand now that the options above sometimes might not fulfill the needs you've initially planned for your Help desk, even being a deal-breaker to some of our customers.

So what is this article about?

Since we still don't have a default way to properly restrict the customer portal by domain, this article provides a quick step-by-step to "block" the creation of issues/tickets from users with undesired domains.

Now, you might be asking yourselves: Why did I add "quotes" in the block word? :)

Basically, this workaround consists in:

1. Identify the domain of the ticket reporter/creator
2. Check if the domain is the one you expect
3. Automatically close the ticket If the customer account uses an unknown/undesired domain, informing the user that no work was done because his account is not allowed to create tickets in the portal and avoiding the ticket from appearing in your queues.

Going to the practical steps: How can I allow only specific domains to create valid tickets in my customer portal?

1. Configure your Jira Service desk to allow any customer to self sign-up, by selecting the option in the Global permissions under Jira Settings > Products > Service desk configuration:
   
2. Also, configure your customer permission under project settings > Customer permissions to allow anyone to create tickets:
   
3. Create a new custom field of the type "Domain of Reporter" and add it to your project screens. This field is automatically filled with the domain of the issue reporter as soon as it gets added to the issue screen.
   P.S: This field is not displayed in the new issue view, however, the workaround still works on it.
4. Under project settings > Project Automation, create an Automation Rule to automatically closes the ticket if the Field "Domain of reporter" is not added with the domain(s) allowed, just like the one below:
   
   
5. Configure the JQL in the queues used by your team to only display the issues created with the expected domains:

   "Domain of reporter" in ("yourdomain.com", "yourdomain2.com")

Troubleshooting any problems: 

1. Make sure your workflow is properly configured with a transition that allows the closure of the issue directly from the initial status.
2. Make sure you have configured the comment of the automation rule to be added as public, so the customers can see and receive notifications about it:
   
3. Double-check if the JQL in the automation rule correctly configured
4. Make sure the automation rule actor has the project permissions to transition, resolve and comment on issues.

Additional to that, I would like to make it clear that these steps only give the option to not consider issues created by undesired domains, however, it will not prevent users from sign-up in your Service desk. It's a temporary workaround while we don't have a supported feature.

Please, feel free to add any thoughts or suggestions you might have in the comments section of the article.

[Pavel Kupriyanov]

This workaround is not good enough - while ticket creation can be blocked, the unwanted visitors could still have access to the portal and the (potentially) confidential materials of the knowledge base. Atlassian should really implement the feature that has been on the requested feature list for 6 years now.

[Petter Gonçalves]

Hello @Pavel Kupriyanov

Thank you for your feedback.

I just would like to clarify that the intention of this article is not meant to decrease the priority or avoid the implementation of the requested features, but to only provide a workaround that may work for some customers while our PMs are still working to implement those feature requests.

I completely understand your point that this is not a useful workaround for your case as you have confidential information in the Knowledge base of your site, but perhaps this can be a temporary solution for other customers using Jira. Again, this is not meant to justify any lack, but to give a possible solution with the current Jira environment.

Best Regards,

Petter Gonçalves - Community Support

[Dana Gould]

Due to the removal of the support for the Domain of Reporter field, this workaround no longer works as documented and recommended here. It needs to be updated while we continue to wait for the desired and much needed security features.

From my experience, the JQL condition can be replaced with an Advanced Compare condition. Based on the troubleshooting I worked out with Atlassian Support, we added a re-fetch of issue data ahead of the Advance Compare condition to handle a race condition involving new customers.

That being said, removing the support of "Domain of Reporter," one of the few workarounds we had for some level of control or monitoring, even if we can find a workaround for the workaround, only further cements our need for the actual tools to control security and access to our company portals.