Customer Permissions for both Internal and External Customers

Question

We are using Jira to provide services to companies where thousands of people (e.g. general public) could request services. This is done today by submitting an email request and having an issue auto created to our agents.

We also use Jira for internal workflow between multiple teams to provide these services.

Due to the general public service, we want to avoid having customers in an organization be able to see other customer names. For example, we want to have customers submit a ticket on a portal, however, when they do they are able to use the Share button and see other people's email addresses (not secure).

Are there any plans to create a Customer Permission or Portal option that would not allow the general public to see other persons in the same organization?

Also, if there are suggestions of how this is best managed it would be great to hear.

Thank you in advance!

Heather

Judd Garratt - Path of Trees · Answer

Hi Heather :)  No problem, Jira is a very intricate thing to wrap one's head around.

Everything you describe is possible with JSM (Jira Service Management). To do this for your project:

* In project settings:* Make sure email is turned on (under 'Email requests') and there is a request type (under 'Request types') associated with the email channel. You can also set up a custom domain for your inbound email. See: Configure email requests for a custom domain.
* Under 'Customer permissions' make sure the service desk is set to 'Open' (so anyone can email in).

* In Jira settings:* Under 'Products' -> 'Customer access' turn on 'Allow portal-only accounts to be created for new customers accessing the help center' and 'Allow customers to create accounts'. This will enable people to email in and have a customer account created (without needing an Atlassian Account).

Then all you need to do is remove the customer organisations to fix the search/leaded details problem. There are instructions at: Remove an organization from a service project. This is the key to making the setup work in a public context like yours.

If you find that customer accounts keep being added to organisations as they join, check your automation rules to make sure there isn't a rule that's doing this in the background.

You might also want to look at 'Project settings' -> 'Customer notifications' as the default email notifications are a bit rough around the edges. There's lots of customisation in there though, so these can be cleaned up quite well.

Let me know if you run into any trouble!

Heather Marquez · Answer

Thanks much Judd! I am still learning the many capabilities of Jira and this instance was implemented prior to me joining the company.  Settings for this example project are in the below screenshot.

Here is a high level of what we are looking to achieve for public facing customers that want to use our service:

* We want public facing customers to send email requests that turn into issue tickets for agents to process
* We don't want to burden these customers with having to create an Atlassian account
* We want to protect the privacy of each customer by not having them see emails/names of other customers
* We need to comment from the ticket and have that be received by the customer
* We need the customer to reply to emails and have those comments seen by agents
* We want to enable the portal to have a more formal intake process outside of just sending an email, while meeting the above criteria

From the research I've done it does not seem possible to achieve this so I'd like to confirm.

Thank you so much!

Heather

Judd Garratt - Path of Trees · Answer

Hi Heather!

At the moment, JSM will always show the share button if a customer is in an organisation (and this will have search enabled).

You can turn off the share button by:

* Removing customers from an organisation AND;
* Ensuring Customers can search for other customers within their organizations, or manually enter the email address of other customers within their project is not selected under 'Customer sharing' on the 'Customer permissions' config page

For a public service desk organisations are often best avoided. If you're using them for something specific at present, there might be another way around this. Happy to share ideas if you can describe more about how you're using organisations currently.

Good luck!