Retrieving the Current Page sys_id in ServiceNow’s Service Portal

In ServiceNow’s Service Portal, every portal page is a record identified by a unique sys_id. Being able to retrieve the current page’s sys_id is important for building dynamic and context-aware features in widgets. For example, a custom navigation widget might need to know which page the user is on to highlight the active menu item, or a widget might log analytics data including the page identifier. In such cases, developers need a reliable way to access the current page’s sys_id during runtime. This information is especially useful when implementing page-specific logic (showing certain content only on a given page) or when debugging to ensure a widget is acting on the correct page. Below, we’ll explore several methods to get the current page’s sys_id in the Service Portal and discuss when to use each approach.

1. Using $sp.getParameter('id') Method

One way to retrieve the current page identifier on the server-side of a Service Portal widget is by using the $sp.getParameter('id') method. This method fetches the value of the id query parameter from the page URL. In Service Portal URLs, the id parameter typically specifies the page to load (either by the page’s friendly ID or its sys_id). For example, a portal URL might look like: /sp?id=homepage or /sp?id=some_page_sysid_value. Using $sp.getParameter('id') in a widget’s Server Script will give you whatever was passed in the URL for id.

Example (Server Script):

In the code above, we first grab the id parameter from the URL. Then we query the sp_page table (which stores Service Portal pages) for a record whose id field matches that parameter. If found, we extract the sys_id of that page. This approach works because Service Portal pages often have a unique string in the id field (like "homepage" or "order_page"). When a user navigates to that page, ServiceNow includes ?id=homepage in the URL, and we can convert that into the actual sys_id of the page record.

When to use: This method is useful in server-side scripts when you need the page’s sys_id for server logic (for example, to conditionally retrieve data or metadata based on the page). It’s straightforward and leverages ServiceNow’s server API.

Limitations: One limitation is that it assumes the page identifier is present in the URL. If the user navigated to the portal without an id parameter (for instance, if a default homepage is loaded without ?id= in the URL), then $sp.getParameter('id') will return null. In fact, if you call $sp.getParameter('sys_id') by mistake (looking for a sys_id parameter instead of id), you will also get null. This is a common pitfall – remember that in Service Portal URLs, id refers to the page, while sys_id (when present) usually refers to a record on a form page, not the page itself. So, ensure you use the correct parameter name. Also, this server-side method runs only on the initial page load for that widget; if the user navigates to a new page via the single-page app (without full reload), the same widget instance would not automatically re-run its Server Script with a new id. In those cases, you would need a different approach (as discussed in the dynamic page changes section below).

2. Using $scope.page.sys_id in the Controller

On the client-side, ServiceNow provides an even easier way to get the current page’s sys_id via the widget’s AngularJS controller. When a widget is rendered on a Service Portal page, the framework injects a special object called $scope.page into the widget’s client-side scope. This object contains information about the current page, including its sys_id, id (the friendly ID or name), title, and other properties. You can directly access $scope.page.sys_id in your widget’s client controller to retrieve the unique identifier of the page.

Example (Client Controller):

In this example, as soon as the widget loads, we log the current page’s sys_id and friendly id to the console. We also check if the page’s friendly ID is "order_page" and set a scope variable accordingly – perhaps to display a section of the widget only on that page. The ability to use $scope.page means the widget already knows which page it’s on, without any extra code to parse URLs or query the server. This is extremely useful for client-side logic. In fact, some out-of-box widgets use this to pass context or record analytics. For instance, a search widget might capture the page ID and include it in an analytics event payload to know from which page a search was initiated.

When to use: Use $scope.page.sys_id in any client-side script when you need to tailor the widget’s behavior based on the current page, or simply to retrieve the page reference for client operations. This approach is useful for dynamically showing/hiding elements, changing labels, or sending the page identifier to the server (perhaps via c.server.get() or spUtil) if needed for further processing.

One thing to note is the difference between $scope.page.id and $scope.page.sys_id. The $scope.page.id is usually the human-friendly identifier of the page (often set by developers for easy reference, like "homepage" or "profile_page"), whereas $scope.page.sys_id is the system-generated unique 32-character GUID for the page record. Depending on your needs, you might use one or the other. For example, to compare against a known page name in client code, $scope.page.id is convenient. But if you need to store or send a definitive unique reference for the page, use the sys_id.

3. Handling Page Changes Dynamically

Sometimes, retrieving the page sys_id once isn’t enough – you need to respond to page changes after the portal is loaded. This scenario arises in long-lived widgets like headers or navigation menus that persist as the user navigates through the portal. In a typical single-page application fashion, Service Portal may change the view without a full page reload when a user clicks a link. The $scope.page object will update to the new page, but if your widget was not rebuilt, you need to detect this change and react to it.

AngularJS $locationChangeSuccess Event: The Service Portal is built on AngularJS, which provides the $location service and the $locationChangeSuccess event. You can listen for this event to know when the URL (and thus potentially the page) has changed. When a new page loads via portal navigation, $locationChangeSuccess fires after the $scope.page object has been updated to the new page. This makes it an ideal hook to run code whenever the current page changes.

Example (Listening for page changes in a widget controller):

In the snippet above, we use $scope.$on to subscribe to the $locationChangeSuccess event. Inside the handler, $location.search().id gives us the id parameter from the new URL (i.e. the new page’s identifier). We then update a controller variable c.activePage. You could just as easily use $scope.page.id or $scope.page.sys_id at this point – by the time this event fires, $scope.page should reflect the new page. The example uses $location.search().id to explicitly grab the identifier of the new page.

Use case – Highlighting the active menu item: Suppose you have a custom menu widget that lists several portal pages. You want to highlight the menu entry for the page the user is currently on. By using the approach above, your controller is always aware of c.activePage. In your widget’s HTML, you can then add a conditional class to highlight the item that matches c.activePage. For instance:

If item.pageID (which could be stored as the page’s id or sys_id for that menu item) equals the current page, the <li> gets an active class, which you can style accordingly (e.g., bold or colored text). This way, whenever a new page is loaded via navigation, the event fires, c.activePage updates, and the UI automatically highlights the correct menu item. The ServiceNow community has suggested this technique for keeping menu highlights in sync with navigation. You can use similar logic for other dynamic needs, such as updating breadcrumbs, showing a page-specific banner, or triggering a refresh of data when the page context changes.

4. Alternative Methods & Troubleshooting

Aside from the primary methods above, there are a few alternative ways to get the current page sys_id, as well as common issues to be aware of:

• Using GlideRecord in a Server Script: If you are in a server-side context (outside of a widget’s client controller) and need the page sys_id, you can query the page using available information. For example, if you only have the page’s friendly name (from some context), you could use a GlideRecord on the sp_page table as shown earlier to find the sys_id. This approach was demonstrated above with $sp.getParameter('id') followed by a GlideRecord lookup. In scenarios like script includes or fixed scripts (where you might not have $scope.page or $location), directly querying the page table by name or other attributes can yield the sys_id. Just be cautious: hitting the database for this is less efficient than using the built-in $scope.page when available.

  
  

• Using $location or window.location in Client Scripts: In addition to $scope.page, you can also leverage the URL directly on the client side. For example, you could use $location.search().id at any time in a widget’s client script to get the current page’s id parameter, even without the $locationChangeSuccess event. Similarly, window.location.href can be parsed to extract the id or sys_id parameters. ServiceNow’s Service Portal is essentially an Angular app, so $location.search() returns an object of query parameters (e.g., $location.search().sys_id would give a record sys_id if on a form page, and $location.search().id gives the page id). This is an alternative if you prefer not to rely on $scope.page, but generally $scope.page is simpler and more direct for the page context.

  
  

• Portal Default Page Consideration: As noted, if a user lands on the portal without specifying an id (for example, just going to /sp and letting the portal load its default homepage), $sp.getParameter('id') will be undefined. In such cases, the portal is loading the default page defined in the portal settings. You can usually detect that scenario by noticing $scope.page.id might be an empty string or the portal’s homepage sys_id matches $scope.portal.homepage configuration. A workaround is rarely needed (since $scope.page will still correctly have the homepage info even if the URL didn’t have an id), but it’s good to remember this quirk when debugging why $sp.getParameter('id') returned null. The solution is to ensure you’re on the correct parameter or use $scope.page which doesn’t rely on the URL query string.

  
  

• Avoiding Common Pitfalls: One common issue is confusion between record sys_id and page sys_id. For instance, on a record form page (like viewing an Incident in Service Portal), the URL will have both an id (page) and a sys_id (record). If you mistakenly try to use current.sys_id in a Service Portal widget’s server script (as one might in a UI Macro or older CMS), you’ll find it doesn’t work because Service Portal widgets don’t have a global current record by default. Instead, you must explicitly get parameters via $sp.getParameter(...) or, in a form widget, use the data the form provides. Always use the Service Portal APIs ($sp, $scope, $location, etc.) rather than legacy global variables. If you get null or unexpected values, double-check that you are using the correct parameter name and context (page vs. record).

  
  

• Sys_id Not Updating on Navigation: If you notice that your widget grabbed the page sys_id on initial load but doesn’t change when you navigate to another page, you’re likely dealing with a widget that persists across pages (for example, a header). The fix, as discussed, is to implement a listener for page changes (using $locationChangeSuccess or a similar mechanism) so you can update the stored sys_id or related state whenever a new page loads. Without this, a persistent widget would continue to display or act on the old page’s context. Testing your widget by navigating between different pages quickly will help catch this — you can use console.log to print $scope.page.sys_id each time and ensure it’s updating.

  
  

• Troubleshooting Tips: When in doubt, use the browser’s developer console to inspect what you’re getting. Logging $scope.page (for client) or using gs.info() for server-side values can help verify if you have the correct sys_id. Another tip is to simulate different scenarios: access the portal page by its friendly name vs. by directly using the sys_id in the URL, and see if your retrieval method still works. This can ensure your code accounts for both possibilities. Also, refer to ServiceNow’s official documentation or community articles for any nuances – for example, the ServiceNow community often shares code snippets and solutions for retrieving URL parameters and handling navigation events in Service Portal.

  
  

Conclusion

Retrieving the current page’s sys_id in ServiceNow’s Service Portal is a fundamental technique that enables more dynamic and context-aware widgets. In this article, we explored how to get the page sys_id using server-side methods like $sp.getParameter('id'), client-side properties like $scope.page.sys_id, and how to handle page transitions using $locationChangeSuccess. The key takeaways for developers are:

• Use the right tool for the context: For one-time needs on page load (especially in server scripts), $sp.getParameter('id') can fetch the page identifier, but on the client side, $scope.page.sys_id is immediate and straightforward.

  
  

• Be mindful of navigation changes: If your functionality needs to react as users move between pages, implement a listener for URL changes so your widget always has the current page’s context.

  
  

• Troubleshoot smartly: If a method returns null, double-check the portal URL and parameter names, and remember that friendly IDs vs. sys_ids might require an extra lookup. Logging and testing in multiple scenarios (direct page load, navigation, homepage vs. subpages) will help iron out issues.

  
  

With these techniques, ServiceNow developers can confidently retrieve and utilize page sys_ids to build responsive Service Portal experiences. As next steps, you might implement a highlight on your portal’s navigation menu using the event-driven method, or use page sys_id to fetch custom configurations (via GlideRecord or portal APIs) for that page. Understanding how to get the current page’s sys_id will empower you to make widgets that are aware of their context and behave accordingly, leading to a more polished and effective Service Portal.