UI Bootstrap in Service Portal You may already be familiar with the $uibModal service in Service Portal, but did you know there is a whole library of useful directives and services available in UI Bootstrap? UI Bootstrap is a client-side library of Bootstrap components written in AngularJS and contains 20 directives that offer a consistent framework, responsive design, and cross-browser compatibility when developing in Service Portal. Although UI Bootstrap is considered feature-complete and is no longer being maintained, Service Portal currently includes UI Bootstrap version 1.1.2. Here are the UI Bootstrap directives. Accordion (ui.bootstrap.accordion) The accordion directive builds on top of the collapse directive to provide a list of items, with collapsible bodies that are collapsed or expanded by clicking on the item’s header. Alert (ui.bootstrap.alert) This directive can be used both to generate alerts from static and dynamic model data (using the ng-repeat directive). Buttons (ui.bootstrap.buttons) With the buttons directive, we can make a group of buttons behave like a set of checkboxes (uib-btn-checkbox) or behave like a set of radio buttons (uib-btn-radio). Carousel (ui.bootstrap.carousel) Carousel creates a carousel similar to bootstrap’s image carousel. Collapse (ui.bootstrap.collapse) Resize window to less than 768 pixels to display mobile menu toggle button. Dateparser (ui.bootstrap.dateparser) The uibDateParser is what the uib-datepicker uses internally to parse the dates. You can use it standalone by injecting the uibDateParser service where you need it. Datepicker (ui.bootstrap.datepicker) The datepicker is flexible and fully customizable. You can navigate through days, months and years. Dropdown (ui.bootstrap.dropdown) Dropdown is a simple directive that will toggle a dropdown menu on click or programmatically. Modal (ui.bootstrap.modal) $uibModal is a service to create modal windows. Creating modals is straightforward: create a template and controller, and reference them when using $uibModal. Pager (ui.bootstrap.pager) A lightweight pager directive that is focused on providing previous/next paging functionality. Pagination (ui.bootstrap.pagination) A lightweight pagination directive that is focused on providing pagination & will take care of visualizing a pagination bar and enable/disable buttons correctly! Popover (ui.bootstrap.popover) A lightweight, extensible directive for fancy popover creation. The popover directive supports multiple placements, optional transition animation, and more. Position (ui.bootstrap.position) The $uibPosition service provides a set of DOM utilities used internally to absolute-position an element in relation to another element (tooltips, popovers, typeaheads etc…). Progressbar (ui.bootstrap.progressbar) A progress bar directive that is focused on providing feedback on the progress of a workflow or action. Rating (ui.bootstrap.rating) Rating directive that will take care of visualizing a star rating bar. Tabs (ui.bootstrap.tabs) AngularJS version of the tabs directive. Timepicker (ui.bootstrap.timepicker) A lightweight & configurable timepicker directive. Tooltip (ui.bootstrap.tooltip) A lightweight, extensible directive for fancy tooltip creation. The tooltip directive supports multiple placements, optional transition animation, and more. Typeahead (ui.bootstrap.typeahead) Typeahead is an AngularJS version of Bootstrap v2’s typeahead plugin. This directive can be used to quickly create elegant typeaheads with any form text input. Check out the full UI Bootstrap documentation here: https://angular-ui.github.io/bootstrap/ How have you used the UI Bootstrap directives in your Service Portal projects? Let me know in the comments below.
Today I am going to show you how to change the styling of the built-in notifications in Service Portal. The default notifications in Service Portal are based on the Bootstrap Alerts components, but I prefer the smaller "Toast" notifications of Bootstrap 4. Default New Style The following CSS sets a new width and aligns the notifications in the upper right corner of the screen rather than spanning the whole page. You will need to add the following styles into a CSS Include in your theme. CSS [crayon-5f99ef38ded0e661121323/] If you are already on the Madrid release, I recommend replacing the above HEX colors with the $brand-success and $brand-danger variables so that they can be driven by the variables defined on your theme. If you wish to trigger notifications from your own widget, you can trigger notifications using either of the following. Server Side: gs.addInfoMessage("Success goes here"); gs.addErrorMessage("Error goes here"); Controller: spUtil.addInfoMessage("Success goes here"); spUtil.addErrorMessage("Error goes here"); BEFORE AFTER This is just a small example of how you can restyle the default notifications, but there is still plenty of ways this could be improved. If you have some ideas or other styles that you would like to share, feel free to post them in the comments below.
WHAT IS "OUT OF BOX" One of the most common requests we hear when developing a portal is, "stay close to out-of-box". People usually think this means staying close to the look and feel of the Stock theme, in hopes that it will minimize complications with future upgrades. This common misconception has very little to do with the portal theme, and everything to do with how many and which widgets were cloned. Staying out-of-box has nothing to do with the theming, look or feel of the portal, but how many of the widgets were cloned. The real danger of “stay close to out-of-box” is that it leaves little-to-no room for: Adhering to company required branding guidelines Delivering a delightful user experience Meeting business requirements So how do you stay close to out-of-box and ensure a smooth upgrade process without sacrificing the look, feel and functionality of the portal? In this article, we'll outline various approaches to help you deliver a portal without sacrificing the user experience. WHAT NOT TO CLONE Before we talk about what you can safely change, let’s talk about what you shouldn’t change. Changing a ServiceNow widget involves cloning it. When you clone a widget, you become responsible for ensuring your widget continues to function as expected after a ServiceNow upgrade. If a widget with complex logic is cloned and you want to align it with the recent upgrade, you may need to analyze both original and cloned widgets line-by-line to determine what changed and to ensure nothing has stopped working. We know from experience that some widgets tend to change quite often, even within patches and hot fixes! For that reason, we recommend that you avoid cloning any widget with complex logic. Some examples include: Shopping cart Catalog item Approvals Order guide Data table Form Before you clone a widget, consider the additional effort it will require to maintain the widget with each upgrade. In many cases, with a little creativity, it is possible to meet business or branding requirements without cloning. WAYS TO AVOID CLONING A WIDGET We’ve found quite a few ways to avoid cloning while still meeting requirements. Here are some suggestions in a rough order of difficulty. INSTANCE OPTIONS Many widgets already have instance options for configuring the behavior and look of the widget. You can access the options by pressing CTRL + Click on the widget and selecting "Instance Options.” CSS Making changes to CSS outside of a widget will have minimal impact on your ability to upgrade. Same thing applies to your layout. With this in mind, don't be afraid to style and theme your portal to make it more attractive and "on brand." WRAPPING/EMBEDDING WIDGETS In some cases, you just need to augment or slightly modify the behavior of a widget. By embedding a standard widget in a custom one, you take advantage of the standard functionality while gaining the control you need. This is useful, for example, when you need finer control over the instance options that are passed to the standard widget or when you need to adapt URL parameters or events. DIRECTIVES From Angular.js documentation: “At a high level, directives are markers on a DOM element (such as an attribute, element name, comment or CSS class) that tell AngularJS's HTML compiler ($compile) to attach a specified behavior to that DOM element (e.g. via event listeners), or even to transform the DOM element and its children.” In simpler terms, a directive could allow you to attach behavior to DOM elements inside a widget you don’t “own.” This is an extremely powerful way to adapt widgets without cloning them. While diving into directive development is beyond the scope of this article, keep it in mind as you evaluate your options. IF YOU NEED TO CLONE In some situations, you can't always avoid cloning to achieve the result you want. If that is the case, be sure you: Document the cloned widgets Consider analysis time as part of your upgrade validation process After an upgrade, evaluate the source widgets to determine if you should Keep the clone "as-is" Upgrade it Revert back to the original Remember, Service Portal is a UI framework built to help you create great experiences. Don’t be afraid to deviate from the Stock theme and take full advantage of all its capabilities! ADDITIONAL READING For related information on the topic, check out these articles. Out-of-Box — Widget Library, ServicePortal Widget Cloning — Clone a Widget Modifying — Widget CSS, Embedding Widgets, Configure Widget Instance Options
By now, you've probably already used the Simple List widget. It is one of the default widgets on the OOB portal homepage. Similar to the Data Table widget, it is used to display a list of records from a table. However, there is a lot more to this widget than you might think. In this post, we will cover some of the secrets of the simple list widget. To give you a quick sample of its capabilities, there is an OOB demo page available at: https://yourinstance.service-now.com/sp?id=test_list Features Include: Display records from any table and filter Support for image fields Show primary and multiple secondary fields Limit the height with scrollable body Trigger an event Customizable actions To get started, let's first create a widget which shows the payload of the event that get's triggered when clicking a record. HTML: [crayon-5f99ef38e184e959637940/] Client Script: [crayon-5f99ef38e1857561221471/] Now if you place this widget on the same page as the Simple List widget, and if you don't specify a "Link to this page" in the Instance Options, you will see the JSON representing the record you clicked on. With this event, it'll be very easy to trigger a modal window or other user interaction, but for now let's proceed to adding some List Actions. LIST ACTIONS The Simple List widget supports adding additional actions for the records in the list. For some reason this related list is not visible on the form by default, so we'll need to add it: Pull up the Platform View of the Instance Record of the Simple List Click the hamburger icon > “Configure” > “Related Lists” Add "List Action -> Parent List" Now you should see the List Actions Related List When adding List Actions, you are able to include properties from the record in the URL field using double brackets: [crayon-5f99ef38e185e327039996/] However, there are a couple of unfortunate limitations: You cannot link to an external URL You cannot use URL prefixes such as “mailto:” or “tel:” Clicking a List Action does not trigger an event This limits the List Actions to just linking to other pages, but hopefully this will get fixed in an upcoming release. DEMO Here is a quick video demonstrating how to configure some List Actions on the Simple List widget. FURTHER READING https://docs.servicenow.com/bundle/london-servicenow-platform/page/build/service-portal/concept/simple-list-widget.html
It’s a pretty common requirement to include images in your widgets, for example replacing the icons with images in the “Icon Link” widget (available here). However, if you have ever added an image field to one of the instance tables, you may have noticed that the images were not included in the update set. This obviously makes it difficult to migrate the portal between instances. The good news is there is a simple solution. SYNCING ATTACHMENTS First, go to a record within the table where you would like to sync attachments (e.g. sp_instance_link) Right click the heading > Configure > Dictionary Select the record where “Type” is “Collection” Click the “Advanced View” related link Paste the following into the Attributes field: [crayon-5f99ef38e29f9871886817/] When completed, it should look like this: Now, the next time you save or update the instance record, the image data will also get included in the update set. NOTE: If you wish to use the image field on all instance tables, you can create the field on the base “sp_instance” table. However, you will still need to follow the steps above for each one of the extension tables where the image field is used.