Service Portal and CMS Thoughts

[Brad Tilton]

Note: This blog post reflects my own personal views and do not necessarily reflect the views of my employer, Accenture.

With the Helsinki release came the highly anticipated release of Service Portal. Service Portal is most widely known as being billed as the successor to CMS, but encompasses much more. ServiceNow defines Service Portal as a visual layer application that is used to render ServiceNow in a visually appealing, approachable way for non-Admin users.

We'll come back to that definition, but let's talk about Service Portal first as a successor to CMS. The bad news is that there is no migration path from CMS to Service Portal as they are built on different technologies. The good news is that if you have a current CMS portal built using the Bootstrap framework you can use most of that design work and styling to give you a head start on building a Service Portal.

One of the biggest differences between CMS and Service Portal is the underlying technology that allows you to retrieve data from the ServiceNow DB and display it on the page. CMS used Jelly which was not a very widely used framework, and thus hard to find any resources on the web as well as developers with Jelly experience. Service Portal, on the other hand, uses AngularJS to take data retrieved from the server and show it dynamically on the page. AngularJS is a very widely used JavaScript framework resulting in many resources, plugins, and experienced developers. Given this choice it should be a lot easier to ramp up a web developer with little ServiceNow experience on Service Portal compared to CMS.

One of the other big differences between the two is that CMS relied heavily on using iframes to display ServiceNow content along with a themed header and possibly a footer. This allowed us to show ServiceNow content fairly easily, but iframes are notoriously difficult to work with and we had little control over what was shown inside the iframe. For example, if you want the catalog content to look more like one of your other internal tools, you didn't really have a lot of options. Service Portal on the other hand is a complete visual layer between the ServiceNow content and the user, so THERE ARE NO IFRAMES, and you have total control over the formatting of the content that is displayed on the page.

The one downside there is that if you have a large catalog with complex catalog items, it may take more work to make those work correctly with Service Portal since it will have to interpret all of those complexities through the visual layer. With CMS we didn't have to worry about how it would be interpreted as it was just being shown in an iframe.

There are a few other major advantages to Service Portal.

• Firstly, it was designed with a mobile first mentality, so it is truly responsive. It was technically possible to make CMS completely responsive, but it took a lot of custom development in order to make catalog items responsive.
• Another major advantage is that Service Portal is a self-contained app on top of ServiceNow, so it will not be as susceptible to upgrade issues as CMS was. CMS typically had default ServiceNow styling applied to it, so as the styling changed throughout releases the CMS site would need its styling changed to accommodate. Service Portal has its own styling and isn't showing any content in iframes, so it's really only reliant on the underlying data structure being consistent.

Overall, if you're starting a new portal build and don't have a large and complex catalog you'll want to use Service Portal. If you have an existing CMS site and/or large existing service catalog you'll need to consider those things before making the decision.

I'll be following this post with some specifics around Service Portal. If you enjoyed this post feel free to like, share, or bookmark it!