Working together with an add-on vendor to solve a customers’ Jira Service Desk cloud challenges
Not so long ago we had a new customer who wanted to have a Jira Service Desk implementation. Next to the normal requirements, like requests and custom fields, the customer had a few other requirements:
- Since they already had Jira Software in the Cloud, JSD should also be Cloud.
- They wanted to retrieve data from a self-hosted database.
- The retrieved data was a considerable list and should be query-able
Well, not too savvy we thought…at first.
Hurdles
The first requirement would not be a problem since we already have quite some experience with integrating external databases with Jira. Unfortunately, this was all with Jira Server not with Jira Cloud. So the normal apps we use to integrate external databases were all for the server or data center options. None of them were available for Cloud. In our quest to find a suitable Cloud alternative we stumbled upon the only suitable app available at that time ( 28 Mar 2019 ): External Data for Jira Fields. One hurdle down, only two to go. At least so it seemed. After reviewing en testing the app it was only suitable for databases which were exposed via REST/URL. And of course, the customer’s database was not. On 15 Apr 2019 we’ve contacted Codefortynine, the vendor of the app, and dropped our feature request for adding MySQL/PostgreSQL database connections. After an hour we already got a response with suggestions on how we could expose our database via REST API and that they were planning on adding the database support in the near future.
To our pleasant surprise, we got an email from Codefortynine the next day. They had good news and they would have pushed the database connection forward and a few days later it was released. That was stellar! In the week afterwards, we tested the connection and suggested some (security-related) improvements, which were implemented the next day! That was the second hurdle down, still one to go.
New functionality
The app already had the option to create a search field, which makes the data source searchable. So we created such a field and that worked right away. Until we start using it from a user perspective. And it became clear to us that it would be a big hassle to use. The select field which showed the external data could contain thousands of items. The items the user was searching for were part numbers. Since there was no possibility to also show the name of the part number, the user could easily make a mistake and select the wrong part number. After the issue had been created, the part name could be shown in a separate side panel. To change the part number, the user needed to open the side panel and then select a different number. All and all searching for a correct part number would be a nightmare.
Once again we turned to the people of Codefortynine and see if they were willing to help us. After explaining our use case and our problem with the current situation, they came up with the following requirements:
- A text field (not a custom field of jira) to search a data source
- The result of that search must be formatted and displayed below the search
- After the verification of the result a trigger (maybe a button) sets that resulted value into a defined custom field of Jira
And after several iterations, they came up with a new field type which they called asset field. This field will search for the criteria you give in and will display only the values that match at that point.
Example
An example. In your database you have the following data:
| Employee | Position | Phone extension | Room |
|---|---|---|---|
| Anne Lee | Sales | 4562 | 101 |
| Anna Hudson | Engineering | 3772 | 203 |
| Harold Johnson | Sales | 3796 | 101 |
| Patrick Dempsey | CEO | 6528 | 301 |
The ‘asset’ is the field Employee. When you search for ‘Ann’, only Anne Lee and Anna Hudson are displayed in the selection field. You can, however, extend the data you display in the selection field. If you also display the position, phone extension and room number you will see the following lines in your search when using the same query:
- Anne Lee – Sales [ext: 4562] – Room 101
- Anna Hudson – Engineering [ext: 3772] – Room 203
But if you change your query to e.g. ‘101’, the result will be:
- Anne Lee – Sales [ext: 4562] – Room 101
- Harold Johnson – Sales [ext: 3796] – Room 101
Which makes the asset field very flexible and easy to use. No more search nightmare!
Cloud restrictions
App development on Cloud is way more restricted then app development on Server or Data Center. We think this is because Atlassian wants to be in control and they don’t want apps to cause downtime, nor do they want that apps are slowing down the user experience. For app builders like Codefortynine, this means that they are limited in what they can do. One of these limits is the amount of external data that can be queried, Atlassian has set the limit to 10k items.
Another issue that we faced (it is the last one we are mentioning here ) is that currently, it is not possible to search the asset field via JQL. When you want to generate reporting and do analysis around the external data that is used, then this can be awkward. To circumvent this problem the app also provides a field that is called ‘dependent field’. With just a few configuration items you can create fields that will display the asset you selected on the view screen (and perhaps some more data of the selected asset) while using the asset field on your create and edit screen. Now you can use JQL to search your external data which is stored in the depending fields.
Karma
By reaching out to the app developers you can present your use case. Most app developers we come across are very willing to help you with your problems and often go the extra mile. When you both are willing to invest some time and effort, you both win. As a customer, you are getting a better solution for the problem you are facing and as an app developer you will not only get a better product, you also get better reviews or as we like to call it: positive Karma.
This blog shows the strength of the Atlassian ecosystem. When partners and app builders work together we can create customer value. We want to thank everybody involved at Codefortynine for helping us and our customer in such a quick manner.
TMC ALM
If you want to know more about what TMC ALM can do for you? Get the professionals of TMC ALM working for you! We can support you with implementation, configuration, installation, training and license management.
Contact us for more information.
