Self service

  • Release version: Zurich
  • Updated July 31, 2025
  • 2 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 Self service

    ServiceNow provides self-service options for applications to enable end users, such as Requestors or Self-Service users, to access and interact with your data model easily. The primary tool for this is the Service Portal, which offers a user-friendly web interface for creating and managing records.

    Show full answer Show less

    Service Portal

    To enhance the end-user experience, use record producers within the Service Portal. Record producers simplify the process of creating application records compared to standard forms. It is important to coordinate with your ServiceNow Administrator to ensure the record producer is properly categorized and accessible within the portal.

    Consider creating a dedicated Service Portal for your application if your needs include:

    • Distinct branding, navigation, or user experience requirements not met by the organization's current portal.
    • The absence of an existing Service Portal in the organization.
    • Need for enhanced functionality beyond default portals.
    • Desire for a more customized user experience than what default forms and lists offer.
    • Greater control over branding and themes.

    Tip: Avoid reusing existing service portal pages directly. Instead, create new pages and reuse components like widgets and headers to maintain modularity and customization.

    Widgets

    Widgets define the content and functionality of the Service Portal. You can use existing base system widgets or develop custom widgets tailored to specific business needs. Best practices for creating custom widgets include:

    • Starting from existing widgets rather than building from scratch, as baseline widgets are read-only to prevent accidental changes.
    • Using the preview pane to quickly test widget behavior before production release.
    • Testing widgets on actual portal pages to ensure proper functionality.
    • Utilizing third-party debugging tools like the ng-inspector Chrome extension for AngularJS.
    • Replacing $rootScope.$broadcast() with $rootScope.$emit() for event publishing.
    • Using widget options to increase reusability by defining user-configurable fields; for unsupported field types, create extension tables for custom schemas.
    • Leveraging Angular Providers to share data and logic across multiple widgets efficiently, improving load times and portal performance by avoiding overloaded client controllers.

    For further guidance, ServiceNow training resources on Service Portal development are recommended.

    Your application may need a way for end users to be able to access your data model, so there are self-service options available.

    Service Portal

    If the application has Requestor or Self-Service users, use Service Portal to provide a friendly web experience.

    To give self-service users the ability to easily create application records from the Service Portal, create a record producer. A record producer can provide a better end-user experience than a regular form. Talk to your ServiceNow Administrator about the appropriate catalog and categorization to make the record producer accessible through the Service Portal.

    Alternatively, create a Service Portal for your app if the following is true:

    The application needs different branding, navigation, or user experience than an organization’s current Service Portal.

    OR

    The organization does not have an existing Service Portal.

    AND

    The application needs more functionality than the default portals provide.

    AND

    The application requires a more customized user experience than the default forms and lists can provide.

    OR

    The application needs more control over branding and themes than the default interface provides.
    Tip:
    Do not try to reuse any existing service portal pages in an application. Create new pages and then reuse components in your pages, such as widgets and headers.

    Widgets

    Widgets are what define the portal content. The base system widgets provided with Service Portal can be used, or developers can build custom widgets to fit business needs.

    Considerations for creating custom Service Portal widgets for an application:

    • Start from an existing widget instead of creating a widget from scratch. To protect existing widgets from accidental modifications, all baseline widgets are read-only.
    • When developing a widget, use the preview pane to quickly test the widget's behavior. Always test the widget on a portal page before releasing a widget to production.
    • Use third-party debugging tools when debugging browser-based applications. For example, the ng-inspector Chrome extension for Angular JS.
    • Avoid the use of $rootScope.$broadcast(). Instead, use $rootScope.$emit() to publish an event to the rootscope.
    • Use widget options to make widgets more easily reusable. The widget option schema defines the user-configurable fields.
    • For field types not supported in the option schema, create an extension table to store a custom widget option schema.
    • Make use of Angular Providers, which are reusable components that can be injected into multiple widgets. To ensure quick loading widgets and a high performing portal, create Angular Providers instead of overloading your client controllers with persistent data and additional logic. With Angular Providers, you can maintain data for the lifetime of your Service Portal and reuse components and data objects across multiple widgets.

    For more information, see Service Portal training.