We're looking to create Organizations in our JIRA Service Desk for use in reporting and in ticket automation.
Is there any way to group Customers into Organizations and make it so they CAN'T view tickets logged by others in their Org?
In my testing, I found the "Private Request" option in the Service Desk Portal. However, selecting this makes it so the ticket is NOT attributed to the user's Org, hiding it from org-based reporting and org-based automation. And when I manually added the user's Org to the ticket after it was created, that made the ticket visible to all other Org users.
Any suggestions would be much appreciated. Thank you!
Keep in mind that there is organization that is attached to an issue and there is organization that a user is a member of. You can use jql to distinguish:
reporter in organizationMembers("") to get all the issues for reporter who belong to an Org
vs Organizations = <name of the org> to get all the issues that are shared with that Org.
Hope that helps
This is all my opinion:
The Organization field is not fully thought out and it feels like JIRA is trying to solve two unique use cases with it.
1) I should be able to use the Organization field to determine what tickets belong to what Organizations.
2) A user should be able to select whether their ticket is public or private to their organization.
A customer's choice to share their ticket should have ABSOLUTELY NO relation to the Organization field. Perhaps another field should be created "Private ticket" with true or false depending on if the user wants to share or not.
So how can one field satisfy both these use cases? It makes no sense.
If one of my agents sees that Organization is blank - Is that because the customer declined to share? Or is that because our workflow failed to automatically set the Organization based on the customer's email domain? Or something else? How do I know the user doesn't want to share the ticket just because the Organization field is blank?
Because of all this, we really need fine grained control over that "Share with" field on the Portal, or a completely overhauled solution to these use cases and my suggestion is to create more fields to house the customer's decision to share or not, and then automatically populate the Organization field from their email domain.
This problem impacts downstream processes like searching for all tickets in an Organization - my search won't return results when the customer declined to share their ticket. And if I go and populate the Organization field where it is missing .... the customer may not be happy about me deciding to share their ticket. This can't be solved with one field.
Yes, Susan's answer of "reporter in organizationMembers("") to get all the issues for reporter who belong to an Org" will help with a search for determining all of an Organization's tickets, but that is a work around to a very poor design decision. The best path forward is to rework the Organization field itself.
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event