Let's focus on the Service Catalog experience in Service Portal for the Jakarta release. Before we begin, there are a few aspects of the catalog you need to have a solid grasp on in order to better understand Service Catalog on Service Portal.

 

  1. Catalog Client Scripts, Catalog UI Policy and Data Lookup support
  2. Supported Variables
  3. Order Guides
  4. Catalog Item/Record Producer layouts
  5. Approach on aligning with the Service Portal way

 

Catalog Client Scripts, Catalog UI Policies and Data Lookups

There is no support for Data Lookups. As for Catalog Client scripts, only UI Type options "Mobile / Service Portal" and "All" will be supported. UI Type "Desktop" catalog client scripts will not execute on the Service Portal. For complete list of APIs supported, see Service Portal & Client Scripts.

 

Finally, all Catalog UI Policies will be supported as long as the APIs listed above are used, when using scripts.

 

Supported Variables

Within the Service Portal, all Service Catalog variables will be supported except for UI Macros, for which you will need to create a new widget and include the same as part of your catalog item. Any validations set up as part of the System Definition > Validation Scripts for variables will not be supported in the Service Portal. The only validations supported are -

  1. Mandatory variables
  2. Read-only variables
  3. Variable visibility - Show/Hide

 

Order Guides

Using Order Guides, customers can submit a single service catalog request and receives a set number of requests. For example, if a manager takes on a new hire they can select multiple items that all new hires can order with one request.

 

For the Order Guides, we do not support the following in Service Catalog within Service Portal:

  1. 3-step checkout
  2. Attachments

 

Catalog Item/Record producer Layouts

In my experience, I have seen our customers build both simple and complex forms. A simple form, in my opinion, is one consisting for no more than eight to ten variables requesting information from the requestor. The variables are usually laid out in a single column layout or a two-column layout, with tab ordering pre-defined so the requestor is guided intuitively through the form. A complex form would consist of more than ten variables, multiple sections built out using containers and complex Client scripts and UI policies which control the user experience on the form.

 

I am a huge proponent of simple forms. There are some advantages to keeping your forms simple:

  1. Simple and intuitive experience for our end users or requestors.
  2. Easy to maintain on a day-to-day basis; as well as, through upgrades.
  3. The experience translates well on different form factors such as desktops, tablets or smartphones

 

Our approach with the Service Portal, and by that I mean Service Catalog on the Service Portal, is to keep the experience simple. Going back to my earlier definition of a simple form, This means that we intend to only support specific aspects.

  1. Two-column layouts.
  2. Any support for Catalog Client Scripts or Catalog UI Policies would be similar to the mobile experience.
  3. Containers and Variable sets within catalog forms will be translated back to the two-column layout.

 

Service Portal catalog layout1.png

 

Service Portal catalog layout2.png

 

 

Service Portal catalog layout3.png

 

The following GIFs demonstrate the different layout examples captured based on our analysis of the various layouts we have seen across our customers. We have attempted to share the most common layouts to utilize. and the GIFs show how these will be rendered within the Service Portal. First, a few of ground rules -

 

  1. Only the top level container settings will be honored
  2. If there are other containers within the top level container, these will be rendered as a single column layouts
    • If there are container splits within these additional containers, these will be rendered as single column layouts as well.
  3. Variables Sets are treated as containers and the above rules apply to Variable Sets as well as containers within them.
  4. Variable Default Size feature coming in Jakarta is not supported on the Service Portal

 

Different types of Service Catalog layouts

The layouts showcased below are also available as part of the attachment to this blog. The file is named "Service Catalog Layouts on Service Portal".

 

Layout example 1: Two containers with variables laid out in single column layouts

Layout 1.gif

 

Layout example 2: Two containers, first container has 2-column layout and the second will be single column container

Layout 2.gif

 

Layout example 3: Nested containers

Layout 3.gif

 

Layout example 4: Nested containers with variable sets

Layout 4.gif

 

Layout example 5: Variable sets with nested containers

Layout 5.gif

 

Layout example 6: Complex nested containers

Layout 6.gif

 

How do I adopt Service Catalog on Service Portal?

The Service Portal is not a replacement for the CMS or the Platform UI, it is only an alternative. The intent with Service Portal is to enable our customers to provide modern, easy-to-use, device agnostic experiences for their end users or requestors. We do not intend to provide full feature parity between the Platform experience and the Service Portal experience.

 

Having said that, we do understand that you may have built out catalog item forms that are fairly complex and do not render well in the Service Portal today. Hopefully, the updates provided above will help you overcome some of those challenges. If they do not, the following is an option that you might find useful.

 

Before we get into the details, I'd like to clarify:

  1. This approach is not a product offering, but only provided as an option that you can use, if you choose to do so. There will be NO SUPPORT for this.
  2. This is intended to be a short-term option so you can continue to use the Service Catalog on the Service Portal, while you set in motion plans to transform your catalog item forms to fit the Service Portal experience.

Lets get into the details now. What we are offering isn't new, it is the age old iFrame solution, but we have made some additional changes that are targeted at masking the iFrame experience, so the difference to the end users is as subtle as possible. The solution consists of the following:

  1. Update Set named "iFramedItem.xml" - As part of this update set, we are adding 2 new fields to the sc_cat_item table -
    • iFrame on Portal - This is a True/False field, with the default value set to false.
    • Support on Portal - This is a String field with max length set to 1000.
  2. Export of Script Include named "Analyzer Script.xml" - Importing this file will add a new Script Include named "PortalCatItemAnalyzer".

 

Once you have applied the update set and imported the script include, you can run the following commands using Background Scripts:

 

var analyzer = new PortalCatItemAnalyzer();

analyzer.analyze();

 

This will only analyze the catalog items (catalog item/record producer/order guide) in your environment and output the results without making any actual changes.

 

var analyzer = new PortalCatItemAnalyzer();

analyzer.analyzeAndSetCatItemFields();

 

This will make updates to your catalog items (catalog item/record producer/order guide). The script will analyze every catalog item to see if it can be rendered on the portal as it was designed in Platform. The parameters include: Nested Containers or Variable Sets, complex scripts which may include either unsupported APIs or ajax calls. If an item is found to be meeting any of these criteria, then the script will set the iFrame on Portal flag to true and update the Support on Portal field with the details of the analysis. Once the flag has been set to true, this item will be displayed within an iFrame on the Service Portal automatically.

 

How a catalog item, a record producer and an Order Guide will be rendered within an iFrame on the Service Portal.

 

 

We have taken care to ensure that all user interactions with these items in the Service Portal continue to keep the user within the portal without exposing the Platform view to them. This includes ordering items, adding them to the cart, editing the cart or clicking on Continue Shopping. Some of the disadvantages with this approach as you might have noticed in the video above:

  1. On catalog items and record producers, you will lose the ability to see the attachment icon. As a result, users will not be able to attach any files during the submission. On ServiceNow Share, please review the Add Attachment Button share from Cloud Sherpas. This provides a way to add a "Add Attachment" button to your forms.
  2. Click-through for the hover-over icon has been turned off and will not be available.

 

My recommendation would be to install the update set and the script include in your dev or sandbox environments first to get a better understanding of how it works. Once the script has been run, depending on how complicated your environment is, the script may take a long time to execute. If you are happy with the outcome, I would suggest installing only the update set in the Production environment and move the updates to the actual items as part of a separate update set.

 

We will continue to enhance the Service Catalog experience on the Service Portal through our next few releases. This will include a combination of bringing existing features on the Platform to the portal and defining newer, more modern UI experiences for the catalog. Stay tuned!!