Zendesk Support for JIRA: Limit Zendesk Support to allowed projects only
Feature Request Summary:
The Zendesk Support for JIRA app should only display/request the Zendesk Support information for tickets under allowed projects.
Description/Use Cases:
Our team uses the Zendesk-JIRA integration for select projects in our JIRA Cloud instance. For projects where the integration is restricted from use, the app still displays Zendesk Support information even though there can be no tickets linked to it. This causes all the teams, who do not work with our Zendesk teams, to see the support fields, which take-up valuable real estate on the issue screen.
Business impact of limitation or missing feature:
A small sub-set of our JIRA projects use the Zendesk integration. This support information is irrelevant to those other projects day-to-day work.
Other necessary information or resources:
https://marketplace.atlassian.com/apps/1211941/zendesk-support-for-jira?tab=overview&hosting=cloud
https://support.zendesk.com/hc/en-us/articles/4408845662746/comments/4563647997594
-
Luke,
I'm not sure if I am fully understanding what you are asking for/saying, but as a customer of both Atlassian and Zendesk, we were able to put limits on who has access to which pieces on either side.
Please note, a majority of the restrictions will need to be put in place on the Jira side, but restricting the app to the necessary Groups and Roles in Zendesk will also allow for limiting access.
For limiting the Jira side, you will want to utilize the documentation list here. Without going into all the configurations we have, we utilize multiple Groups, separate project spaces (i.e. some teams use the company default template, while others build their own rules and policies for their Project Boards), and various Roles under those spaces. On top of this, different projects utilize different schemas to display data.
If you really want to just start with some basics, I would look at updating the schema used for the various teams, instead of using one default schema for all. The schema will allow you the ability to have fields available versus not.
To further clarify on how my company went about the integration, we also implemented the "Jira Field-Mapping", which allowed us more flexibility on what data was being transferred across and synced with various fields. There were a couple of items (i.e. URLs to ZD ticket and Jira issue) we couldn't natively sync, so we used Workato to get those items synced.
I hope this information helps. If this doesn't, please clarify your issue a bit more and I might be able to provide you with some insight on how I was able to "make it happen".
~Konstantin
I don't work for Zendesk, just a Certified Support Administrator. -
Thanks for the info. Sadly, this isn't a group/permission issue.
We are curious about making the support panel go away for JIRA tickets without a Zendesk link. On the side of every issue view in our JIRA instance we see the, "Zendesk Support" tabs.
We get the impression this is just some global panel the integration app adds without any configuration on our end.
Image uploading appears to not be working but here is the link to an example: https://support.zendesk.com/hc/user_images/fkDRVwMA0SLvdf2RSvLC3Q.png
-
Ahh, I see what you mean; And yes, that is native to the overall integration, as that allows a way for teams to communicate with each other between the two systems. As for the linked tickets, that really comes down to potentially a process change.
I say this, as my company had to decide how we wanted specific items to be linked for a semi-similar reason. For example, our Major Incident tickets needed to be linked to one Jira issue, while our Engineering and Development related items had to be submitted as a single issue in Jira, then set a Parent issue/Epic for the individual customer items.
It does become a bit cumbersome at times to have to remember all these as an Administrator, but due to our specific compliance standards, something that is just "understood" we have to deal with. I apologize I couldn't be of more help on this, but am always willing to help any way I can.
~Konstantin
-
I guess I should clarify a bit further on my company's setup...
In Zendesk, we have the Jira app limited to a small number of Groups and Roles. Those agents generate a new ticket (based off the customer ticket) with specific details, that gets assigned to another Group (this is where our Jira linking starts). We do this to limit the type of Zendesk information passed over to the teams working in Jira.
In Jira, we have our various teams broken out into Groups and Project spaces, with various configured Roles. On top of this, we have different schemas (i.e. Screens, Fields, etc.) in place for the various teams, to ensure we limit necessary data for each Group. We also utilize the "Field-Mapping" option for the Jira app, to assist with mapping data over, and allowing us to better customize screens for visibility (if data is easier to see in one spot, people have less of a tendency to go to other areas).
And as stated in my previous comment, we then have some processes in place on how we handle specific situations, to ensure we are following our compliance standards. The Role and Group restrictions assist with ensuring people only have access to their issues, while other individuals can have access to their "Parent".
~Konstantin
-
Hi Mike Konstantin,
The standard integration solution does not provide a whole lot of customisability indeed. If you are still looking for a better integration experience allow me to propose an alternative that is specialised for these types of integrations.
Have a look at Exalate. It's a solution that allows firstly both sides of the integration to define which data is being send an how the incoming data is being processed. While allowing for a very flexible way to automate the ticket/issue sync without any user interaction as long as the criteria set is met.
You can have a UI element to show the sync status + remote link and have the ability to remote the UI element all together if this is not required.
Please sign in to leave a comment.
5 Comments