I'm new with Jira configuration. Any guidance would be appreciated.
I've been tasked with setting up a service desk ticketing system for our team. We service several different companies and would like to keep each of their queues separate and private from one another while allowing anyone on our team at Gunpowder to assign, task and communicate with the end user.
From what I've researched it's not possible to have a single project with a single support portal, while maintaining privacy across the queues. https://jira.atlassian.com/browse/JSDCLOUD-1954
I'm wondering what would be the best approach to this? Would we be able use Automation Rules and Issue Security Schemes to have a single project with secure issues in each queue? Or is it really just best to make multiple projects for each client?
Thanks in advance for any input!
All the Best,
Oh, got it. Thanks for the clarification. I was under the impression that any customer with access to the projects portal would be able to see anyone else's ticket. So I guess my real question is how to automate the separation of different organizations tickets into separate queues based on their email domains?
Welcome to the community.
In Service desk there is the concept of "agent" users and "customer" users. "Customers" in your case would be the companies to whom you provide service. "Agents" are your team members who work on the tickets.
The issue you references concerns how to make the Queues visible based on teams of Agent users, not Customer users.
This article talks about how to keep items private between one customer company and another within a single Service Desk project.
You would set up an Organization for each customer Company. Then for each individual customer who submits a request, you would assign that individual to an Organization. You decide if they can see or share their issues with other customers through the settings described in the article above.
Thanks again for the reply. I've had a chance finally to look at this and look at our current configuration. It's looking like there's a hundred different ways to do the same task in Jira... Nice to have all these options but it makes the learning curve substantial when trying to accomplish what would seem to be a fairly simple task!
I've added all the Orgs within the project and added all the customers to their appropriate Orgs. My next question is, what would be the easiest way to have each of those Orgs have their own private queue? Also, what would be the best workflow to have the tickets automatically get separated into the appropriate queue, can I do this within JIra automation, somehow based on the domain of the email?
Thanks again for any insights.
Can you clarify what you mean by a "private Queue"? Who should be allowed to see the issues in the "queue" and who should not, among both the agents and the customers? Are you trying to limit which agents can see issues across customers, or are you trying to ensure that customers see only issues related to their Organization?
In Jira Service Management "queue" is the term used to refer to lists of issues as seen by Agents within a Service project. Customers don't see the "Queues". Customers see their issues through the Customer Portal interface and they will see only the issues they have individually created or issues that have been shared with them. There are settings available around sharing issues that help constrain what the customer will be able to see.
Agent views of Queues in a Service Project
Customer views through the Customer Portal
Regarding which tickets a customer can see and how they can proactively share them with other customers, you'll need to specify a variety of options to govern that. Refer to this document:
There are "global to Jira Service Management" settings that you need to look at also. One in particular is used to specify if customer tickets are shared with all the other users in their Organization by default. You can find those settings here:
It is apparently not currently possible to automatically add a new customer to an Organization based on their domain. There is a change request about that here:
...and this article discusses a work-around