Widgets and Demo Portal from our K18 Service Portal Sessions

Due to popular demand, here is a quick video highlighting the portal and some of the widgets we showed during our CreatorCon sessions at Knowledge18. We've made the following widgets and applications available for download: Gamification for Service Portal https://serviceportal.io/gamification-in-service-portal/ Unlocking Service Portal Widgets https://serviceportal.io/downloads/k18-creatorcon-example-widgets/ If you've found this content useful or if you have any special requests for upcoming posts, please let me know in the comments below.

The Road to Kingston: Route Maps (Part 2 of 3)

This is a 3 part series that will take a deeper look at the new Service Portal features found in the Kingston release. In case you missed part 1, checkout the link below. Part 1 - Announcements Part 2 - Route Maps Part 3 - Order Guides Link to official ServiceNow Kingston Service Portal Release Notes Route Maps for Service Portal One of my favorite features in the Kingston release is the new Page Route Maps. Lets say you're working on a new custom portal, but you would like to leave the out-of-box portal intact. One of the custom pages of the new portal is a User Profile page, in the past you would've either renamed the out-of-box page ID, or used a new page ID and then updated any links found throughout the portal. The problem with this is that the links are sometimes hard-coded in the out-of-box widgets, that you would now have to clone just to change the URL. In Kingston this has been solved by simply creating a new Page Route Map. When to use Page Route Maps Cloning out-of-box pages Multiple portal environments with differing pages Restrict access to a page New Configuration Records The following configuration records have been added to ServiceNow to provide support for the new Page Route Maps feature: New Table Page Route Map [sp_page_route_map] New Module Page Route Maps [Service Portal > Page Route Maps] Creating a New Route Map Using our example from before, if we would like to link our portal to a new User Profile page without changing any of the existing links, all we have to do is: Navigate to Service Portal > Page Route Maps. Click New. Complete the form. In this example, the out-of-box page is called "user_profile", and our new page is "user_profile_2". With this new Route Map, any request at the original URL on a designated portal will render our new page. Before: After: Final Thoughts The Route Maps are a great addition to the Service Portal. Due to the Service Portal's modular nature, Page Route Maps finally complete the full circle of being able to quickly and easily change the page that is rendered without changing URL's. h5,h4 { margin-top: 24px; margin-bottom: 18px; } h4 { color: #3d89cc; } .aligncenter { text-align: center; } .entry-content { border-top: 1px solid #ddd; }

Creating a sticky footer in your Service Portal

While developing web layouts, at some point you've probably run into the issue with the footer floating in the middle of the page just below the content. This can easily be fixed with a little CSS magic. Service Portal does support fixed headers and footers, but this causes the footer to stick to the browser window and overlap the content, which is not what we want. We want the footer to always be at the bottom of the page. This is called a "sticky footer".   In between Helsinki and Istanbul some major changes were to made to the outer page structure that broke some earlier solutions posted on the community. My goal is to provide a solution that would work with all versions of Service Portal and it's various supported browsers. The Solution: I've chosen to implement the sticky footer using Flexbox as this provides the most amount of flexibility. One added advantage of flexbox is that it also supports variable height footers, which many other solutions do not. Installation: Go to your portals theme record. Select a footer widget, you can use the out-of-box "Sample Footer" as a test. Make sure the "Fixed footer" checkbox is unchecked. Paste the following snippet of CSS into the "CSS variables" textarea, or alternatively you can include it in a CSS Include. [crayon-5b2f28ee0719b140652826/] It's been tested on Helsinki, Istanbul, and Jakarta using Chrome, Safari 9+, IE10+. For additional information on flexbox, you can check out the following resources: A quick guide to flexbox by CSS-Tricks - here. Solved by Flexbox, a website dedicated to cool flexbox techniques - here. I hope you've picked up something new and useful from this article. Would love to hear your comments and questions in the comment section below.

Communicating between the Client Script and the Server Script of a widget

We've had a lot of questions about how the client side and server side of a widget can communicate, so this week I thought it would be a good idea to offer a quick demonstration. In this tutorial we will create a widget that allows the user to add or remove items from a list. In this case it's just a simple Array, but it could just as easily be using GlideRecord against a table. Here is the sample code used in the video: HTML: [crayon-5b2f28ee09428160777315/] Server Script: [crayon-5b2f28ee09432861411048/] Client Script: [crayon-5b2f28ee09437393616370/]

Create custom action buttons in Service Portal

A common feature request for Service Portal is to be able to add custom buttons to the sc_request or ticket page similar to the way you could add UI actions to a form. This functionality is not available out-of-box, but here is a quick example on how you could create a custom widget to display some buttons to mimic the UI Actions on a form. In this example, we will create a "Resolve Incident" button to place on the incident "ticket" page. HTML: [crayon-5b2f28ee0a04a755626456/] Client Script: [crayon-5b2f28ee0a053507809155/] Server Script: [crayon-5b2f28ee0a058125140663/] The resulting widget should look something like this: This is far from the complete solution, but will hopefully provide a good example to work off of.

Using Events to Communicate Between Widgets

Following the principle of “separation of concerns”, it is good practice for your portal or application to be made up of self contained functional components, also known as widgets in Service Portal. However sometimes these widgets need to communicate with one another. Thanks to Angular.js this can be accomplished through the use of $broadcast, $emit, and $on methods. $broadcast and $emit allow you to raise an event in your widget. The difference between $broadcast and $emit is that the former sends the event downwards from parent to child controllers, while $emit sends an event upwards from the current controller to all of its parent controllers. Both methods are available on $scope and $rootScope. You can subscribe to an event using the “$on” event handler. In this example we will create two widgets that interact using $broadcast and $on. Widget #1: Create two buttons that upon click, will $broadcast an event called "customEvent" and pass an object. HTML: [crayon-5b2f28ee0c615860795283/] Client Script: [crayon-5b2f28ee0c61f767745010/] Widget #2: Listen for the "customEvent" event, and when triggered, the callback function will update the text. HTML: [crayon-5b2f28ee0c624967061710/] Client Script: [crayon-5b2f28ee0c62a236979263/] The final results should look like this:

Creating an Angular Directive in Service Portal

Directives are one of the many important components available in Service Portal thanks to Angular.js. You've probably already used many of Angular's built-in directives without knowing it, such as: ng-repeat, ng-model or ng-class. But did you know you can also develop and use your own directives in your Service Portal widgets? To illustrate a very basic example, let's navigate to the "Angular Providers" module, and start by creating a new record with the following: Name: "spButton" Type: "Directive" Client Script: [crayon-5b2f28ee0d781029942797/] To use your Angular Provider you will need to associate it with a widget by linking the two together using the "Angular Providers" related list on the widget form. Now you can use the directive within any of the HTML of that widget. For example: [crayon-5b2f28ee0d78a662953955/] Note: The name of the directive is camel-case "spButton," however when used in HTML, it needs to be hyphenated (e.g. spButton -> sp-button). Now when that widget is rendered, you will see the following button any time that directive is used: When this button is pressed, it will bring up an alert with the message, "Hello World".

Widget Options Schema & Instance Options

One of the very powerful features of the Service Portal is the "Widget Options Schema" which enables developers to create a set of dynamic options on the widget. This allows for the widget to pull dynamic data from the instance without needing to modify the actual form of the instance. You can define the options schema by either: In the portal, hold [CTRL] + right click on the widget, and select "Widget Options Schema" In the Widget Editor, click the hamburger menu and select "Edit options schema"   In the options schema modal, you can create the options by clicking the "+" button and setting the field name, label, and field type. The following types are currently supported: String Boolean Integer Reference Choice Field_name Field_list Once the schema has been defined, you can set the values to be used on the instance by holding down [CTRL] and right clicking the widget in the portal and selecting "Instance Options". Once the Instance Options have been set, you can now access the option values using the "options" object in the widget, which is automatically made available in the Server Script, Client Controller, and HTML. See the following examples: Client Controller: [crayon-5b2f28ee0e483224627907/] Server Script: [crayon-5b2f28ee0e48c942781397/] HTML: [crayon-5b2f28ee0e491532411259/] A good example of this could be as simple as a Title Widget where now the widget can be used all throughout your portal, but the title is different each time it is used since the title is being pulled from the instance. This allows your widgets to be very configurable and reusable. I highly suggest you start using it with your portals and custom widgets today.