CMS to Service Portal transition
Summarize
Summary of CMS to Service Portal transition
This guide assists ServiceNow customers in transitioning from CMS to Service Portal, focusing on adapting CMS and Service Catalog implementations for Service Portal adoption. It highlights key differences, unsupported components, and necessary modifications to ensure optimal user experience and functionality in the mobile-friendly Service Portal environment.
Show less
Customers should be aware of the impact on mobile usage and review related GlideForm scripting and migration guidance. Redirecting CMS users to Service Portal requires additional configuration as redirects are handled differently.
Supported Components and Transition Actions
- Data Lookups: Client-side data lookups are unsupported in Service Portal, but server-side updates occur correctly upon record submission. This limitation mainly affects requester roles.
- Content Blocks and UI Macros: Both rely on Jelly and are unsupported. Replace them with widgets, which offer customizable functionality and can be managed using the Service Portal Designer. For complex scenarios, develop AngularJS widgets.
- UI Actions: Server-side UI actions are supported except setRedirectURL() calls, which must be refactored since Service Portal handles redirection differently. Client-marked UI actions are ignored.
- Catalog Client Scripts: Only scripts marked for Mobile/Service Portal or All UI types are supported. Desktop UI type scripts and synchronous JavaScript calls (e.g., getXMLWait()) are unsupported and must be updated to asynchronous methods.
- UI Policies: Scripts must use APIs supported by Service Portal. Unsupported client APIs should be removed.
- Service Catalog Variables: Supported with exceptions: UI Macros, UI pages, and validation scripts are unsupported. Help text and instructions are always expanded; the Help tag does not display. List Collector variables render as choice lists. Testing is recommended to verify help text display.
- Order Guides: Use the Order Guide widget. Large guides may degrade performance; consider splitting or simplifying them. As a temporary workaround, render items via iFrame.
- Record Producers: Supported with caveats: sorting by catalog item is not honored, and date values may ignore time zones. Thorough testing is essential.
- Login and Redirects: Service Portal uses the SPEntryPage script include for login scenarios instead of CMSEntryPage. Redirects are unsupported; instead, configure login behavior through SPEntryPage and system properties.
- Service Catalog Forms: Rendered in two-column widget layouts. Complex forms with nested or multiple containers collapse into two columns. Default variable sizes and expanding/collapsing help text are unsupported. Simplify complex forms or use iFrame rendering as a temporary solution.
- Shopping Cart: Service Portal provides a base Shopping Cart widget to use for cart functionality.
Practical Recommendations
- Replace Jelly-based content blocks and UI macros with widgets for compatibility and customization.
- Review and refactor client scripts and UI actions to conform with Service Portal’s supported APIs and asynchronous scripting requirements.
- Simplify complex Service Catalog forms and large order guides to improve performance and display consistency.
- Test all record producers, catalog items, and variables thoroughly in the Service Portal environment to identify and resolve any behavioral differences.
- Adjust login configurations using SPEntryPage and system properties in place of CMS redirect scripts.
- Consider temporary use of iFrame rendering for complex catalog items during transition.
By following these guidelines, ServiceNow customers can effectively migrate their CMS implementations to Service Portal, ensuring a responsive, mobile-optimized, and maintainable user experience.
Your CMS may include complex forms and customizations that do not render as expected in Service Portal. Use this guide to understand how best to modify your CMS and Service Catalog implementation for Service Portal adoption, and to understand how a conversion may affect your users.
If you are considering transitioning from CMS to Service Portal, make sure that you understand the impact of moving to a mobile environment. Review the Mobile client GlideForm (g form) scripting and migration.
Support level and transition actions
| CMS component | Service Portal support |
Possible transition actions |
|---|---|---|
| Data lookups | The client-side component of a data lookup is not supported in Service Portal. However, the data lookup is applied in the platform when a record is submitted or updated in Service Portal. |
While data lookups are not applied in the Service Portal, the record updates as expected in the platform UI when submitted or updated in the Service Portal. If your CMS is used by requesters only, this limitation may not affect your implementation. |
| Content blocks | Because Content blocks use Jelly, they are not supported in Service Portal . |
In the Service Portal, content blocks are replaced by widgets. Widgets are highly customizable components that can query record data, display and update records, and gather user input. Base system widgets generally cover most use cases. Just as you add content blocks to a page in your CMS, you can add widgets to a page using the Service Portal Designer. |
| UI Macros | Because UI Macros use Jelly, they are not supported in Service Portal. |
|
| UI actions | All server-side UI actions are supported in Service Portal, although setRedirectURL() operations are ignored because Service Portal forms handle redirection in a different way than the platform. The form widget ignores all UI actions marked as Client. |
|
| Catalog client scripts |
Only UI Type options Mobile / Service Portal and All are supported. UI type Desktop is not supported in Service Portal. For a list of supported APIs, see Service Portal and client scripts. Note: Synchronous JavaScript calls are not supported in Service Portal and
must be replaced by asynchronous calls. For example, the getXMLWait()
method of the GlideAjax class is not supported in Service Portal. Instead,
use one of the following supported asynchronous methods:
For additional information on GlideAjax, refer to GlideAjax. To understand the impact of updating your CMS to work in a mobile environment, review Mobile client GlideForm (g form) scripting and migration. |
|
| UI policies | Scripted UI policies can only use APIs supported in Service Portal. For a list of supported APIs, see Service Portal and client scripts. |
Update your scripts to remove any unsupported client APIs. |
Service Catalog variables |
Service Catalog variables are supported in Service Portal with the following exceptions:
|
|
| Order guides | Order Guides in Service Portal use the Order Guide widget. |
Large order guides can cause performance issues in the Service Portal. If you have large order guides, you can:
|
| Record producers | Record producers are used in Service Portal with the following differences:
|
Make sure to test all record producers used in Service Portal to make sure that they behave as expected. |
| Login scenarios and redirects | In CMS, you used the CMSEntryPage script include to define login scenarios. Instead, Service Portal uses the SPEntryPage script include and related system properties to define login scenarios. Redirects are not supported in Service Portal. |
In Service Portal, define login behavior by modifying the SPEntryPage script include and setting system properties. For more information, see Single sign-on, logins, and URL redirects. |
Service Catalog forms |
Service Catalog forms such as catalog items and record producers are rendered within widgets in a two-column layout. Complex forms may not display as expected.
|
|
| Shopping cart | The Service Portal includes a base system Shopping Cart widget. |
Use the Shopping Cart widget. |