CMS to Service Portal transition

  • Release version: Yokohama
  • Updated January 30, 2025
  • 5 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of CMS to Service Portal transition

    This guide helps ServiceNow customers understand how to transition from CMS to Service Portal, especially when dealing with complex forms and customizations. It highlights necessary modifications for CMS and Service Catalog implementations to function correctly in Service Portal and explains the impact on users, particularly when moving to a mobile environment. Customers should review mobile client GlideForm scripting and related migration details before transitioning.

    Show full answer Show less

    Key Considerations for Transition

    • Data Lookups: Client-side data lookups are not supported in Service Portal but are applied upon record submission or update. This limitation may not affect requester-only CMS implementations.
    • Content Blocks and UI Macros: Both use Jelly and are unsupported in Service Portal. Replace them with widgets, which are customizable components for querying and updating records and gathering input. Widgets can be added via Service Portal Designer and developed using AngularJS for custom needs.
    • UI Actions: Server-side UI actions are supported except for setRedirectURL() operations, which must be refactored as Service Portal handles redirection differently. Client-marked UI actions are ignored.
    • Catalog Client Scripts: Only scripts with UI types "Mobile / Service Portal" or "All" are supported. Desktop UI type and synchronous JavaScript calls (e.g., getXMLWait()) are unsupported and should be replaced with asynchronous methods.
    • UI Policies: Must use APIs supported in Service Portal; unsupported client APIs should be removed.
    • Service Catalog Variables: Supported with exceptions. UI Macro and UI Page variable types and validation scripts are unsupported. Help text behavior differs, always expanded, and List Collector variables display as choice lists. Testing is recommended to ensure expected display.
    • Order Guides: Use the Order Guide widget; large guides may impact performance. Consider breaking large guides into smaller ones or simplifying variables. As a temporary workaround, catalog items can be rendered via iFrame.
    • Record Producers: Supported with caveats: sort order of catalog items is not preserved, and date values do not honor time zones. Testing for expected behavior is necessary.
    • Login Scenarios and Redirects: CMS used CMSEntryPage for login scenarios; Service Portal uses SPEntryPage script include and system properties. Redirects are not supported; login behavior is configured via SPEntryPage.
    • Service Catalog Forms: Rendered in two-column layouts within widgets. Complex forms with nested containers may not render as intended, as only top-level container settings apply and nested containers flatten into single columns. Default variable sizes and multi-column layouts beyond two columns are unsupported. Simplify complex forms or use iFrame rendering as a temporary solution.
    • Shopping Cart: Service Portal provides a base system Shopping Cart widget for use.

    Practical Actions for Customers

    • Review and update client scripts and UI policies to comply with Service Portal supported APIs and scripting standards.
    • Replace Jelly-based components like Content blocks and UI Macros with widgets and develop custom widgets as needed.
    • Test all Service Catalog variables, order guides, and record producers for expected behavior in Service Portal, especially focusing on layout and data handling differences.
    • Adjust login scenarios by configuring the SPEntryPage script include and related properties.
    • Simplify complex forms to fit the two-column layout constraints of Service Portal or use iFrame rendering as an interim measure.
    • Utilize the Shopping Cart widget included in Service Portal for shopping cart needs.

    Following this guidance ensures a smoother transition from CMS to Service Portal, preserving functionality while adapting to Service Portal’s architecture and mobile-first environment.

    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.

    Note:
    For information about redirecting CMS users to Service Portal, see the How to automatically redirect users who navigate to any CMS pages to Service Portal [KB0722455] article in the Now Support Knowledge Base.

    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.
    • In Service Portal, you can use widgets instead of UI Macros. Base system widgets generally cover most use cases, but for custom solutions, you can develop new widgets using AngularJS.
    • If your implementation includes UI Macros in Service Catalog forms that reference other fields or variables in the form, you can embed the widget inside a Service Catalog variable. Learn more: Replace a Service Catalog form script with a widget.
    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.
    • Refactor any UI actions to remove setRedirectURL() operations.
    • Check that UI actions are not 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:
    • getXML(Function callback)
    • getXMLAnswer(Function callback)

    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.
    • Update your scripts to remove any unsupported client APIs.
    • Check that the script UI Type is set to Mobile / Service Portal or All.
    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:

    • UI Macros and UI pages variable types are not supported.
    • Validation Scripts for variables are not supported. Supported validation types include:
      • The Mandatory field on the variable form.
      • Read-only variables.
      • All fields in the Availability tab of the variable form.
    • Default variable size is not supported.
    • Expanding and collapsing help text is not supported. Rather, the Help text and Instructions fields defined in the Annotations tab on the variable form are always expanded. The Help tag does not display.
    • The List Collector variable displays as a choice list instead of a slushbucket in the Service Portal.
    • If embedding a widget in a catalog item form, you can use the UI Macro variable type. Learn more: Replace a Service Catalog form script with a widget.
    • If using variable with annotations, make sure to test your catalog items in Service Portal to ensure that help text displays as expected.
    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:

    • Break them into multiple order guides.
    • Simplify variables used in the order guides.
    • As a temporary solution, you can render the Service Catalog item using an iFrame. See Service Catalog forms in Service Portal.
    Record producers

    Record producers are used in Service Portal with the following differences:

    • The sort order for catalog items in record producers is not honored.
    • Date values do not honor time zone when the record producer submits a record.

    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.

    • Only the top-level container settings are honored. If there are other containers within the top-level container, they are rendered as a single column. If there are container splits or nested containers within these additional containers, they are rendered as a single column. A top-level container is not a child of any other container.
    • There can be a maximum of two columns in Service Portal. If your implementation includes forms with more than two columns, the fields are reorganized into two-columns in Service Portal.
    • Variable sets are treated as containers. All previously listed rules apply to variable sets as well as any containers within them.
    • Default variable size is not supported in Service Portal.
    Shopping cart

    The Service Portal includes a base system Shopping Cart widget.

    		 Use the Shopping Cart widget.