Portal Tip – Sexy Service Catalog Icons + Layout
Joe_Burrows
Cireson Devops Super IT Monkey ✭✭✭✭✭
Recently with the Portal v5 feature additions; the new service catalog layout and the advanced request offerings we thought it was well overdue to give our Support Portal some tender loving care to better suit this new layout and get rid of the tired looking icons. Prior to the recent changes we had a pretty basic service catalog, request offerings for report Portal bug, report Asset Management bug, ask question etc. A quick and obvious win is use advanced ROs to replace all the different raise an issue ROs into one with dynamic questions. The problem we faced were tickets were coming through as incidents that should really be service requests and service requests were coming through that should be incidents.
Supporting and screen sharing with our customers daily here at Cireson I’m lucky enough to be inspired by how customers extend and flavor SCSM with our products to suit their individual company needs. I always liked the idea of giving end users a visual representation of what they are raising so they can differentiate what offering is an incident and what offering is a service request. A common theme is icons are tiles and each tile color represents incident or service request, for example color is red or green representing “I want” vs “somethings broken”.
I wanted to take this idea a step further and copy the incident and service request icons used in Service Manager, BUT where are they? I could not find these hunting around the installation paths so after asking doctor google I stumped upon the below blog post:
http://blog.scsmsolutions.com/2012/04/list-of-images-available-in-scsm-2012/
This gives me the image name and management pack ID of exactly where these live in service manager so with the below PowerShell I am able to extract the icon and customize to my heart’s desire.
IncidentMgmt_AllIncidents_32 ID: c47d4397-a09a-f6ee-9551-1d1d8b7cfd23
ServiceRequest_32 ID: 0f2e8dec-f175-b4c5-34ce-35b01e058f60
Get-SCSMImage -Name IncidentMgmt_AllIncidents_32.png
Get-SCSMImage -Name ServiceRequest_32.png
Using Gimp I can add these as a layer to some new icons, which I’ve found by picking some pretty images from free icon websites off the internet.
The new service catalog layout in v5 allows for a service offering page where you can see an overview plus all associated request offerings and KB articles. We choose this as a way to break up incidents from requests and nest these under a category for the Cireson support team:
Using some HTML tags in the instruction field of the RO we also are giving users a link to the raise a request service offering page in case they land here and realize their ticket is not an incident
With the new upcoming enhancements there will be the ability to direct link from an RO straight to an external page, hence why we now have a new icon in the bottom right hand corner so you can tell which RO’s will direct to community vs raise IR\SR.
Currently in its BETA state ROs do not direct link if launched from top
requests, but when it does I’m hoping to have two new request offerings in the
top requests spot so they redirect to the service offering landing pages for “Raise
an Issue” and “Raise a Request” so end users are presented the correct choices
of what services we at Cireson Support offer.
Another popular tool used for icons is Metro Studio:
https://youtu.be/h52ZODX5g9gFeel free to show off your service catalog layouts or icon making tips below.
Comments
With regard to the direct link RO, is a record kept when a user makes the request? It would be beneficial to know the volume and popularity of ROs that are not handled via SCSM/Cireson portal.
Leigh, how would you like us to track this, as a int in the db, or registering a SR that automatically completes so you can run reports etc?
If you had a single table in the db that contained RO and Submission DateTime, you could use that data in a dashboard. Something like "Top RO's this week/month/quarter".
If you included additional data such as "Affected User" and/or Submitter (in the case of a Tech using On Behalf), you could get lots of additional data there.
An int in the db would be perfect, particularly if it also counts the ROs that result in an SR. That way we'd avoid issues multi-sourcing data and dealing with archived WIs.
Thanks Chris.