Is there any way natively to make the JSM portal for a specific project look better or at least not horrible? It's just a comma separated list of the Request Types and is nearly impossible to read. Any suggestions would be helpful/appreciated.
Do you have a single JSM project that houses all of these request types? Several of the requests look like the wouldn't fall under an IT service desk. If it were me, I would make different JSM projects (IT, HR, etc.) and have the relevant requests fall under each of those. It would certainly clean things up.
The other thing I notice is that you have extremely granular requests that make it a bit crowded as well.
This is all housed within a single project to give users a single place to go to request support, access, tools. etc. We have also built out a rather complicated process for assigning requests to teams rather than individuals, automating sub-tasks based on options selected, tying in manager approval based on LDAP data from Jira Assets, etc.
We also have other JSM portals with specific use-cases (Change Management, Incident Management, etc) so moving these requests all into separate projects and expecting the user to know to select Name Change rather than Change Management if they got married and changed their name isn't an option.
We are migrating from datacenter where we use a plug-in (Theme Extension for JSD) to make the portal look really good. Unfortunately the same plug-in doesn't work offer the same functionality in the Cloud and the Refined plugin doesn't look good on the submission form (field names are too close to the field above and look like they're tied to the wrong entry field).
I'd like to stay with the native functionality, because it's superior in most aspects, but the submission portal looks terrible even if you only have 5 forms in a single category and the customization options are extremely limited. Additionally, the Search bar is obscured and not easy to find. This is more of a training issue that I can find a way to address with our 12k users, but looking at that eyesore is not.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Currently the answer is no, the listing you see in each group are all the request types that you have assigned to that group.
I would question why you have so many request types for application support. My guess is that you would be able to combine a lot of them into a single request type and then use Forms instead. Another option if the request types you have are product specific but they all have the same fields on them would be to utilize Assets, you could then have one generic request type and use an Assets field to select the product the request is for.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Honestly, Application Support is just the general bucket that everything has been thrown into as it's the first tab on our current service desk. We can and plan to break it out further, but any more than 2 or 3 forms in a category look awful and 30 categories doesn't look any better.
The requests cannot be combined as they have different workflows. We have customized the workflows pretty heavily to allow for skipping past/applying various levels of approval, but changing the workflow altogether will not work for auditing reasons.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
This is what we have today and it just looks awful.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.