Service Portal is a compelling
alternative to the Content Management System (CMS) with a refined user experience. It does not
duplicate CMS or platform UI functionality. Users who have sophisticated experiences delivered
through CMS may need to invest time into transitioning to Service Portal, especially if the CMS
implementation includes complex and customized Service Catalog forms.
Service Portal compatibility with
existing CMS sites
ServiceNow continues to support CMS in
current and upcoming releases. If you have existing CMS sites and activate Service Portal on your instance, your CMS
sites will continue to work, as CMS and Service Portal are separate
applications.
Differences between Service Portal
and CMS
Service Portal is an alternative to
CMS based on more modern technologies. Major differences include:
- Underlying technology
- CMS uses Jelly, which is not a widely used technology. Service Portal instead uses AngularJS, server-side JavaScript, HTML, and CSS. Any scripts that use Jelly
do not work in Service Portal.
Building widgets in Service Portal requires knowledge of AngularJS.
- Visual layer
- CMS uses iFrames which can be difficult to work with, limited in terms of styling,
and susceptible to upgrade issues. Alternatively, Service Portal is a self-contained
application that accesses data from other tables on the platform. This enables
fine-tuned control over style and responsive design.
- Mobile first
- Unlike CMS, Service Portal is
optimized for a mobile environment. For this reason, the following apply to the Service Portal environment:
- Any scripts used in Service Portal can only use
APIs supported in a mobile environment. For example, some APIs used in your Service Catalog client
scripts may not be supported. For a list of supported APIs, see Service Portal and client scripts.
- Service Portal forms
support a maximum of two-columns. As a result, any highly customized Service Catalog forms, such
as catalog items and record producers that use containers and variable sets,
must be simplified to work in a two-column layout.
If transitioning to Service Portal, review the following resource: Mobile client GlideForm (g form) scripting and migration.
To understand how core CMS components are configured in Service Portal, refer to the following
table.
Table 1. CMS and Service Portal components
| CMS component |
Service Portal
equivalent |
| Content site |
Portal |
| Content page |
Page |
| Content types |
Content types link a table to a content page.
In Service Portal, content
types are no longer required. Record data is queried and displayed using base
system widgets. You can add widgets to any number of Service Portal pages.
Learn more: Service Portal widgets.
|
| Layout and dropzones |
In Service Portal, pages
are made up of containers, rows, and columns.
Learn more: Pages.
|
| Content block |
A content block is a reusable piece of content.
In Service Portal, content
blocks are replaced by widgets.
Learn more: Service Portal widgets.
|
| Service Catalog |
Service Catalog pages
are rendered using the SC Catalog Item widget in Service Portal. For this
reason, Service Catalog
forms such as catalog items and record producers are shared between your CMS
implementation and Service Portal. If you have a
highly customized Service Catalog, you may
need to invest time in simplifying your Service Catalog items and
client scripts so that they render as expected in Service Portal.
Learn more: Service Catalog forms in Service Portal.
|
| Theme |
Theme |
| CSS |
CSS |
CMS and Service Catalog
customizations
Service Portal comes with base system
widgets to address common use cases and to display record data. Even though there is no
direct migration path from CMS to Service Portal, there may be some items,
such as catalog items or knowledge articles, that render as expected in Service Portal without any effort.
However, because Service Portal is
supported in a mobile environment, you may need to modify any customized forms and scripts.
This approach ensures that the items display well on a mobile device and present a better
user experience. Before transitioning to Service Portal, you may need to:
- Refactor client scripts used in your CMS/Service Catalog to use supported
mobile APIs and global objects. For a list of supported APIs, see Service Portal and client scripts.
- Build widgets to replace UI Macros and other unsupported scripts. If using a UI Macro
in a catalog item form and referencing values on the form, you can use the following
workaround instead: Replace a Service Catalog form script with a widget.
- Simplify any complex forms used in your Service Catalog to fit the Service Portal two-column form
layout.
- Consider which release supports the required functionality. You may want to upgrade
your instance before transitioning to ensure that you have the required base system
features.
