I’m a PM on the Jira Service Management (JSM) ecosystem team. I would love to understand your top 3 asks as it pertains specifically to JSM extensibility. In order to get focussed responses, please do not include other topics such as Forge, Jira platform extensibility, pricing, general ecosystem needs, and so on.
we do indeed have a few things that would help us a lot, as we use JSM APIs quite a lot for our app.
JSM portal currently uses a lot of private APIs to get most of the information, it would be really helpful to have most of them public. E.g. information that is currently missing from the public APIs:
Portal announcement message
Portal customizations (e.g background image)
Service Desk descriptions + images
Request type group description texts
Expose an API that allows retrieving a list of “Services” (ITSM) for a request type/service desk. Currently, we cannot create requests with the API because there is no way to get a valid list of services
ADF support for comment/description-related REST APIs It’s currently a hassle to send comments in ADF, you have to post the comment in JSM API, then update it in the Jira Platform API with the ADF you want.
APIs to edit the templates for customer emails. For our Read Receipts app, we need the JSM project admin to add the snippet to the email template that contains the tracking pixel. It’d be great if we could do that for the admin.
to replace the default Customer Portal to offer a custom experience (think of it like a generalPage module for JSM). An administrator could choose which custom-portal (offered by installed apps) to use for his service desk. Could work like Confluence themes.
to control the request types a user is able to use
Thanks for taking time to get feedback from us, we have been reporting subjects for a while now and some have been stuck without any answers.
Here are our main subjects:
Our Elements Connect for Jira Cloud integrates inside the Create Request form on JSM portal. It provides select list with options coming from external datasource. We need to have dependencies with Jira fields to have issue context. In a JSM context, we would love to be able to register on public events send by JSM on frontend so our select lists can refresh live.
Events would be fired every XXXms on user input changes.
Hi Jullian, thanks for your feedback. With regards to controlling the request types a user is able to use, we’ll first need to build this on JSM cloud. The functionality does not exist today. About accessing Insight REST APIs, @valente has responded on this thread.
Hi I think there are a few low-hanging fruits that would improve JSM extensibility a lot at least for my use case.
I provide pre-configured projects with fields and workflows to help automate various specific business tasks. Unfortunately, I am quite restricted with the Service Desk API and might need to basically redevelop things like the queues view and the request forms because some API endpoints, while very simple and existent for a good time now (meaning that they are unlikely to change) are simply not published. I tried accessing them via user impersonation but I am encountering 401 errors even though the oauth token of my connect app is working properly. Committing to these endpoints and making them public would in my view enable more business use cases for Jira, something that I believe is aligned with Jiras long-term goals given how many different templates you already have. Here my top asks
Provide a more complete Create/Update Request Type API endpoint that allows updating fields not just based on the field configuration since that makes a few features such as attachments (which can’t be made required) or non-required fields impossible. As far as I can see there is already a simple private API that is used when using the UI, all you would need to do is document and publish it. Assigning request types to groups is also a fundamental feature that I am missing from the request type API.
Publish the API for creating, editing and deleting queues.
I can’t decide which one is more important but I have two more APIs that I would like to have access to. Allowing to edit customer notifications would be another very simple task since the API for this is very simple. On the other hand, editing and creating new SLAs would also be useful but there are more options to this and it will be a bigger task to document it and handle invalid requests.
I would be happy to help out with the documentation and testing of these endpoints if that would make them available sooner.