It seems like every release brings with it a new Workspace, and with it either some new functionality or a shiny new coat of paint over some familiar capability. With the introduction of the Next Experience in the San Diego release, ServiceNow began the parade of “Configurable Workspaces,” or “Experiences,” that have now become the vehicle for enabling enhanced AI and other advanced capabilities on the platform.

Here we will look at the state of these Workspaces and how they impact the usage, architecture, and design of solutions for ServiceNow. For more detailed information, see the ServiceNow documentation: Next Experience UI (servicenow.com).

Workspace Overview

Prior to the Next Experience, ServiceNow dipped their toes in the enhanced UI waters by introducing the Agent Workspace (and the ability to create your own Workspaces using the framework). This would lay the groundwork for introducing what we now know as “Configurable Workspaces,” but as of the Washington DC release is no longer shipped, supported, or available for activation. Thus, for the remainder of this article the term “Workspace” is used to refer to the Next Experience configurable workspaces.

The Next Experience uses an implementation of “Web Components” (learn more about Web Components here) to encapsulate functionality within discrete units on a page to achieve the following benefits:

1. Allow complex functionality to be packaged into self-contained and reusable units
2. Avoid code sprawl encountered when reusing controls that require complex HTML, scripts, and styles
3. Prevent conflicts between different implementations of similar blocks of code where styles or events and functions may overlap

Each component functions in a similar way to an “Interface” (see this page for a good description of interfaces in object-oriented programming) in that it defines a set of inputs (if necessary) and returns a set of outputs (also if necessary) while leaving the details of how the functionality is implemented up to the internal code. It is, in other words, a promise of a specified or agreed upon result but not a promise of how that result is achieved. This means that any JavaScript library can be used to implement the code within the component. And this is precisely why the Next Experience was built using this methodology: the internal workings of the component can be changed in any future release to use more efficient, simpler, or just different libraries without the platform needing to be entirely re-architected. The component is effectively future proofed as long as the new implementation uses the same inputs and outputs and returns the same result.

That is a big deal.

However, it’s important to note that, as of this writing, Workspaces are not meant to replace every UI on the Now Platform. There are now three primary interfaces in ServiceNow: Service Portal for the end-user experience; Workspace for the fulfiller experience; and what is now known as “Core UI” (or the “backend” or the “admin UI” or the “frameset UI” or… well, it goes by many names) for System Administration as well as other Fulfiller processes that have not yet been gifted with their own workspace (emphasis on “yet”).

Workspaces do not yet support the “responsive” layout that Service Portals offer, and with continued development on several portals (Employee Center and the Customer and Consumer Service portals, for example) it does not appear that there is any rush to replace Service Portal with the Next Experience just yet.

Now that we understand a bit more about Workspaces, let’s look a little closer at some of the benefits and challenges they present.

The Promise of Workspaces

Going back to the Agent Workspace, the concept of a dedicated space that would ease access to information and supercharge productivity was the driving force behind introducing this new user experience paradigm. The idea was to encapsulate the various things a fulfiller would need to do work while remaining in a single browser tab. From a focused landing page and a targeted set of record lists to a structured work area that could use nested tabs to ease navigation without losing your place, the promise of Workspaces was to simplify the fulfiller experience under a single pane of glass (I promise that’s the last time I’ll use that term in this article) to make work as efficient as possible.

Often fulfillers need additional context when working on a task, such as information about a user, configuration item, Customer Account, or other related entity. Workspaces offer a consolidated view of this related information by either presenting it as a sidebar for the current record or allowing related records to open in a new tab within the same page so that users don’t have to navigate away from a record or open a new browser tab (which affects the browser’s history stack and can often cause frustration when the “back” button takes you somewhere you didn’t expect).

Additionally, most of the new capabilities (including the fast-expanding GenAI solutions) are exclusively released for and accessible from the new Workspaces. Now Assist, Playbooks (the portions for fulfillers), Recommended Actions, and other capabilities are not accessible in the Core UI, so adoption of these capabilities will also require adoption of Next Experience Workspaces.

If you have not already at least explored the various Workspaces, now is a good time to get started as they will only become more ingrained in the platform.

The Challenge of Workspaces

Every ray of sunshine casts a shadow, and it is no different with Workspaces. Along with all the promise, benefits, and new capabilities come real, and not insignificant, challenges to adoption, development, and maintenance.

Challenge 1: Silos and Sprawl

Considering users first, one of the main challenges of adopting Workspaces is the sheer number of them. Each workspace is designed for a specific Persona and Use Case, and the functionality is designed to support it. Unlike Service Portals, where any page can be used within any portal, each page (and with it, the functionality offered by the page) in a Workspace is defined only for that Workspace and cannot be used or accessed from elsewhere. This poses significant usability challenges when a user’s responsibilities cross multiple personas. In these cases, they may have to toggle between multiple Workspaces as they work through their processes.

A specific example relates to the intersection of Request Fulfillment and Asset Management. For many organizations, the Service Desk (the consummate IT Fulfiller) is responsible for fulfilling hardware and software requests for their end user base. Along with this responsibility, they may also manage stock for the equipment they provide. So, what happens when a user requests a new laptop?

Well, when Procurement is in use the first thing to happen (after approvals) is a “Sourcing” task for the entire Request. This task is meant to identify how the requested hardware will make its way to the fulfiller to supply to the requester. The request may be fulfilled from local stock, it may require transfer from another stockroom, or it may need to be purchased from a supplier.

As a result of such purpose-built workspaces, it can often be a challenge for a user to know where they need to be for a specific task or a specific step in a larger workflow. Clear and accessible documentation along with good training can help mitigate this risk, as well as some clever design to try to bridge across Workspace silos, such as providing navigation options when a task is best worked in another Workspace.

It may also be possible to mitigate some of this conflict by adding capabilities to other workspaces, however this would require a non-trivial level of effort to “copy” a page and its functionality from one Workspace to another. The copied pages and other artifacts would also need to be kept up to date with changes to the source page.

Challenge 2: Self-Configuration

Beginning with Homepages, one of the most powerful capabilities that ServiceNow offers is the ability to empower users to create what they need to be as productive as they can. Being able to build targeted reports, consolidate them onto a page, and share them with your team has been a mainstay of the platform since its inception, and is the main reason I fell in love with it so many years back. It was the root of my career transformation and the inspiration for my mission to spread that transformation as far and as wide as I can.

Now let’s talk Landing Pages. Each Workspace hosts a Home or Landing page, and it is possible to create “Variants” of the landing page that can be surfaced to a user depending on the roles they have (we will talk further about Variants a bit later). The Landing page is meant to provide key data for the user upon entering the Workspace to help answer the question “What do I need to work on next?” So, it would seem this is akin to Dashboards. But alas, this is not the case.

Landing pages, while they support Variants, are not adjustable or sharable by the user. Each Variant must be built by someone with what amounts to administrative access within the Workspace. Dashboards are still accessible though the Platform Analytics Workspace (see the documentation for more information), and it is possible to add Dashboards to a dedicated page within a Workspace (see the documentation for a specific implementation for the CSM Configurable Workspace), but given the newly siloed nature of Workspaces (see Challenge 1) it is no longer as intuitive or seamless.

Workspaces do still offer a level of personal configuration, specifically by allowing you to define your own “Lists” for quick and specific access beyond what is configured for the Workspace in general. The interface also still allows you (for the most part) to configure list layouts and to personalize forms, and certain pages offer personalization or configuration preference options depending on the page content. However, the loss of quickly and easily creating and sharing Dashboard content is a big one.

There are not a lot of options available to mitigate these challenges, other than providing good training and documentation to ensure users know where to find things like Dashboards and understand what they are able to configure themselves. You can also look to add a “Dashboard” page to each Experience, which will ensure that users remain in the experience when clicking through any report content to view the lists and records.

Challenge 3: Development and Maintenance Complexity

ServiceNow released UI Builder as a way to configure and develop within the Next Experience framework. They also allow building custom components (although they generally discourage this). However, building a custom component requires significant additional expertise and advanced tooling, as components must be built off-platform in a command line interface or other IDE, that most seasoned platform developers and architects do not have. And for many of us, the learning curve is a bit too steep.

The power and promise of ServiceNow is that it obscured the underlying complexity of building an Enterprise-grade application and allowed folks with moderate scripting abilities to build amazing experiences. Next Experience introduces an entirely new lexicon along with purpose-built architecture that looks similar to, but is distinctly different and separate from, familiar entities like Script Includes and UI Actions.

One need only attempt to explore an existing page in a Workspace to quickly grasp the complexity and multi-layered architecture upon which many pages are built. Often sub-pages are nested within a Viewport in an existing component, and that sub-page may contain additional viewports wherein additional pages are nested, and so on. It is often a struggle to locate the component you are looking to investigate.

Additionally, the nature of Page Variants can make testing a challenge. Each Variant is given an order within a page route, and the first variant for which a user matches an Audience (as well as a match on any page conditions) will display when accessing that route. As an administrator, it can be difficult to access a particular Variant when testing, as the “all roles” nature of the admin role means that you will likely match the Audience of the first Variant by order. That fact can make changes to a variant somewhat difficult to test, although you can impersonate a user with the intended Audience in another session to make testing a bit easier.

The ServiceNow developer community has been hard at work delivering content and enablement for UI Builder. At the moment, I can only recommend that you invest the time to explore the available content, leverage the collective community for advice and support (as this amazing community has done for decades now), and build up your capabilities and comfort level with UI Builder. Additionally, a light touch is the best solution and I recommend modifications in the Workspace only as a last resort, using Page Variants where possible, and with very comprehensive documentation. In the meantime, keep open communication with ServiceNow’s product managers, who are very active and open to dialog, with the intent of working collaboratively to ensure the platform continues to work for all of us.

Challenge 4: Capability Gaps

New Workspaces are introduced quickly in response to an ever-changing environment. As a result, sometimes the functionality they are meant to replace is not completely covered in the first release. ServiceNow has adopted an agile approach to this challenge, with frequent store releases occurring outside of the Major Family Release schedule aimed at providing evolving capabilities at a faster pace.

As an example, consider the evolution of the Project Workspace. When it was first released, it was limited to the new Planning Console and lacked the “Details” page to allow users to see the complete Project record; the other navigation options still linked out to the “classic” project workspace. Over the course of several Store releases, the “Classic” pages were added to the new Workspace, and as of Xanadu if you do a fresh install then the “Classic” navigation is now gone completely. There remain, as of this writing, several functions that elude the new Workspace, such as adding Test Phases to the Project from the Planning Console and preventing Child Tasks from being added to an Agile Phase.

The best way to mitigate this challenge is to carefully plan your adoption strategy. Establish a minimum capability threshold below which you cannot adopt a Workspace and then monitor the road map and releases to know when that threshold is reached. You can also identify which pieces of functionality it may still be possible to access outside of the Workspace (or is there is a way to embed it into a tab or modal, is that an option?) and explore a hybrid and phased approach to adoption. ServiceNow does a good job of regularly adding capabilities to the Workspaces, so it is likely only a matter of time until you reach critical mass and can begin adopting.

The Path Forward

Although I spent more time focusing on the challenges posed by Workspaces, my intent is not to cause despair. Having spent time working within these experiences, looking at the constant growth the steady stream of super impressive capabilities, and the simple fact that they are not going anywhere, I am hopeful that Workspaces and the tools underlying them will continue to evolve and fulfill the ServiceNow mission of making it as easy as possible to “enable regular people to create meaningful applications to route work through an enterprise.”

The power of the Now Platform lies within its community. That includes not only the users, administrators, and developers that use the platform to carry out their mission, but the folks at ServiceNow that enable those users, administrators, and developers by listening to their needs and producing a product that is unmatched in its ability to empower and inspire every day. My hope is that we continue to collaborate to make it as easy as possible to create and deliver value from this amazing platform.

The post We Need to Talk About Workspaces appeared first on ServiceNow Guru.

In this article I’ll show you how you can use GlideDialogWindow to pop open a dialog containing any custom UI Page information you want. I’ll also show how you can pass information into those dialogs, and how you can return information from those dialogs back to the standard form that initiated the dialog. These dialogs can be initiated from any place where you can use client scripts…client scripts, UI Macros, UI Actions, etc.

The example I’ll use here is based on one that a ServiceNow developer wrote as an example. It’s not very fancy, but it’s simple enough to show how things work without adding a bunch of confusing elements. It simply opens a dialog with information populated from the form and returns information from the dialog to the form.

The first piece of this solution is to set up some mechanism to trigger your GlideDialogWindow. For this example, I’ve chosen to use a UI Action button. Here are the details of the button. The comments in the script explain how to initialize the dialog and pass parameters on to your UI Page to populate information there.

function commentsDialog() {
//Get the values to pass into the dialog
var comments_text = g_form.getValue("comments");
var short_text = g_form.getValue("short_description");//Initialize and open the Dialog Window
var dialog = new GlideDialogWindow("task_comments_dialog"); //Render the dialog containing the UI Page 'task_comments_dialog'
dialog.setTitle("Add Task Comments"); //Set the dialog title
dialog.setPreference("comments_text", comments_text); //Pass in comments for use in the dialog
dialog.setPreference("short_text", short_text); //Pass in short description for use in the dialog
dialog.render(); //Open the dialog
}

Once you have your UI Action set up to trigger the dialog, you need to make sure that you have the correctly-named UI Page to display in the dialog. In the script above, we used ‘var dialog = new GlideDialogWindow(“task_comments_dialog”);’ to initialize a GlideDialogWindow and point to the ‘task_comments_dialog’ UI Page. Here’s what that page looks like. The comments in the HTML below explain each piece of the UI Page. The client script portion of the UI Page is used to validate the input on submission of the dialog form. If validation passes, the value of the ‘Comments’ field on the dialog is passed to the ‘Comments’ field on the original form.

<table width="100%">
<tbody>
<tr id="description_row" valign="top">
<td colspan="2">${jvar_short_text}</td>
</tr>
<tr>
<td colspan="2"></td>
</tr>
</tbody>
</table>

function validateComments() {
//Gets called if the 'OK' dialog button is clicked
//Make sure dialog comments are not empty
var comments = gel("dial_comments").value;
comments = trim(comments);
if (comments == "") {
//If comments are empty stop submission
alert("Please provide comments to submit the dialog.");
return false;
}
//If comments are not empty do this...
GlideDialogWindow.get().destroy(); //Close the dialog window
g_form.setValue("comments", comments); //Set the 'Comments' field with comments in the dialog
}

The post GlideDialogWindow: Advanced Popups Using UI Pages appeared first on ServiceNow Guru.

Let’s walk through how this can be done with a handful of updates and relatively little trouble. The goal of this is to put a user photo just under the Caller field on the incident form so that the person working the incident can see who they’re working with. This could have numerous benefits ranging from a verification that you’ve got the right person in a walk-up scenario all the way to showing the agent on the phone that it’s a real person they are interacting with, prompting a little more thought into how they can truly help that person.

To set this up we need to understand that there are a couple places where the image might be stored. In the early days of ServiceNow it would have always been on the user record. But now we have collaboration tools built in and some great functionality within Service Portal and other areas that utilize the Live Profile which includes the user avatar photo and ability to easily update it.

This is most easily updated by users in Service Portal from the Profile page.

To set this up we need four main components and then a quick update to the form layout to add the Live Profile Photo to it.

First we need to set up a UI Macro that acts as our container on the form for the photo. It contains a simple div with an ID that we target from within a client script.

<!--?xml version="1.0" encoding="utf-8" ?-->

<script>
		function cf_setLiveProfilePhoto(photo_path){
			jslog("Setting photo to: " + photo_path);
			try{
				// Get the div from below so we can set the contents to the image
				var photo_div = document.getElementById('cf_live_profile_photo');
				if(photo_path){
					// This uses the thumbnail size image from the Live Profile and keeps the image small on the form
					var photo_html = "${LT}img style='max-width: 40%;' src='" + photo_path + "?t=small'/>";
					// This uses the full size image that was uploaded and scales it down to fit the space. 
					// This will generally produce a larger image and depending on the form, images, and 
					// space available, this may be a preferable option.
					//var photo_html = "${LT}img style='max-width: 40%;' src='" + photo_path + "'/>";
					photo_div.innerHTML = photo_html;
				} else {
					// No image was specified so clear out the div
					photo_div.innerHTML = '';
				}
			} catch(e){
				jslog("Unable to update photo: " + e.message);
			}
		}
	</script>
<div id="cf_live_profile_photo" style="text-align: center;"></div>

After that we need to create a Formatter that lets us place that UI Macro on the form.

Now we need to create the script include that will look up the user photo. This first checks the live_profile record for the logged in user and if nothing is found there, checks for a photo on the user record.

var cf_LiveProfile = Class.create();
cf_LiveProfile.prototype = Object.extendsObject(AbstractAjaxProcessor, {/*
* Retrieves the user photo from the Live Profile, if possible, otherwise
* gets the photo from the user record if possible.
*
* Returns the path to the photo or an empty string
*/
getPhoto: function(){
// Get the Sys ID of the user that we're retrieving the photo for
var user_id = this.getParameter('sysparm_user_id');
gs.log("getPhoto called for: " + user_id, "cf_LiveProfile");
var photo_path;

// Query for the live profile record
var live_profile_gr = new GlideRecord('live_profile');
live_profile_gr.addQuery('document', user_id);
live_profile_gr.query();
if(live_profile_gr.next()) {
if(live_profile_gr.photo.getDisplayValue()){
photo_path = live_profile_gr.photo.getDisplayValue();
gs.log("Retrieved photo from live profile: " + photo_path, "cf_LiveProfile");

}
}
// Check to see if we have a photo from the profile
if(!photo_path){
// No profile photo found, query for the user photo
var user_gr = new GlideRecord('sys_user');
user_gr.addQuery('sys_id', user_id);
user_gr.query();
if(user_gr.next()) {
photo_path = user_gr.photo.getDisplayValue();
gs.log("Retrieved photo from user record: " + photo_path, "cf_LiveProfile");
} else {
photo_path = '';
gs.log("No photo found", "cf_LiveProfile");
}
}
return photo_path;
},
type: 'cf_LiveProfile'
});

The last component before we add this to our form and see the photos is to set up a Client Script that will listen for a change in the user reference field on the form. For our example, this is the Caller field on the Incident form, but it could easily be shown on a different table. The important thing is that the reference field be for the User [sys_user] table.

function onChange(control, oldValue, newValue, isLoading, isTemplate) {
if (newValue === '') {
cf_setLiveProfilePhoto('');
return;
}// Call back to the server to get the path of the user's profile picture
var ga = new GlideAjax('cf_LiveProfile');
ga.addParam('sysparm_name','getPhoto');
ga.addParam('sysparm_user_id', newValue);
ga.getXMLAnswer(function(answer){
cf_setLiveProfilePhoto(answer + '');
});

}

Now that we have all of these components set up, you should be able to go to the Incident form and add “CF Live Profile Photo” to the form layout. Then when you change the Caller field to a user that has a photo you should see the photo show up.

Thanks to Dan Andrews for the idea!

The post Add a user profile photo to a form appeared first on ServiceNow Guru.

The first example is the full set of blocks on the Service Portal homepage as shown in this screenshot.

This can be replicated by taking the following steps…

1) Create a new UI page with the following settings

<!-- Contains the HTML and CSS necessary for all styling and layout. Feel free to modify if need be. --> <style type="text/css">
    .homepage-quicklinks {<br />        background-color: #ffffff;<br />	    font-family: "SourceSansPro", Helvetica, Arial, sans-serif;<br />        font-size: 14px;<br />    }<br />	.text-info {<br />        color: #31708f;<br />    }<br />	a.text-info:hover, a.text-info:focus {<br />        color: #245269;<br />    }<br />	.text-success {<br />        color: #5cb85c;<br />    }<br />	a.text-success:hover, a.text-success:focus {<br />        color: #449d44;<br />    }<br />	.text-warning {<br />        color: #f0ad4e;<br />    }<br />	a.text-warning:hover, a.text-warning:focus {<br />        color: #ec971f;<br />    }<br />	.text-danger {<br />        color: #d9534f;<br />    }<br />    a.text-danger:hover, a.text-danger:focus {<br />        color: #c9302c;<br />    }<br />	.text-muted {<br />        color: #979797;<br />    }<br />	a.circle_icon {<br />        display: block;<br />        padding: 20px 0px 20px 70px;<br />        position: relative;<br />    }<br />	a.circle_icon .fa {<br />        position: absolute;<br />        left: 0px;<br />        top: 10px;<br />    }<br />	a.circle_icon h3 {<br />        font-weight: 300 !important;<br />        padding: 0;<br />        margin: 0 0 10px 0;<br />    }<br />	a:hover {<br />        text-decoration: none;<br />    }<br />	a:visited {<br />        text-decoration: none;<br />    }<br /></style>
<h1 style="color: #717171; font-size: 3em; text-align: center;">Welcome to ServiceNow!</h1>
<div class="homepage-quicklinks" style="background-size: initial; background-position: center center;">
<div>
<div class="row">
<div class="col-sm-6 col-md-3">
<div>
<div><a class="circle_icon text-info" href="catalog_home.do?sysparm_view=catalog_default" target="" rel="noopener">
<span class="fa fa-stack fa-2x">
<i class="fa fa-circle fa-stack-2x"></i>
<i class="fa fa-shopping-basket fa-stack-1x fa-inverse"></i>
</span></a>
<h3>Order Something</h3>
<span class="text-muted">Browse the catalog for services and items you need</span>

</div>
</div>
 

</div>
<div class="col-sm-6 col-md-3">
<div>
<div><a class="circle_icon text-success" href="kb_home.do" target="" rel="noopener">
<span class="fa fa-stack fa-2x">
<i class="fa fa-circle fa-stack-2x"></i>
<i class="fa fa-book fa-stack-1x fa-inverse"></i>
</span></a>
<h3>Knowledge Base</h3>
<span class="text-muted">Browse and search for articles, rate or submit feedback</span>

</div>
</div>
 

</div>
<div class="col-sm-6 col-md-3">
<div>
<div><a class="circle_icon text-warning" href="com.glideapp.servicecatalog_cat_item_view.do?sysparm_id=3f1dd0320a0a0b99000a53f7604a2ef9" target="" rel="noopener">
<span class="fa fa-stack fa-2x">
<i class="fa fa-circle fa-stack-2x"></i>
<i class="fa fa-fire fa-stack-1x fa-inverse"></i>
</span></a>
<h3>Report an Issue</h3>
<span class="text-muted">Contact support to make a request, or report a problem</span>

</div>
</div>
 

</div>
<div class="col-sm-6 col-md-3">
<div>
<div><a class="circle_icon text-danger" href="#" target="" rel="noopener">
<span class="fa fa-stack fa-2x">
<i class="fa fa-circle fa-stack-2x"></i>
<i class="fa fa-comments-o fa-stack-1x fa-inverse"></i>
</span></a>
<h3>Live Chat</h3>
<span class="text-muted">Start a chat conversation with customer service agents</span>

</div>
</div>
 

</div>
</div>
</div>
</div>

2) Create (or edit if you’ve already go one) a widget record

The widget record is what will allow you to add the widget to a ServiceNow homepage. The following example could be used in your system. You can add multiple widgets to the script of any widget record. The key is to include your widget UI page by referencing it in the widget ‘Script’ field. You can access widget records by navigating to ‘System UI -> Widgets’.

function sections() {
return {
'Welcome to ServiceNow!' : { 'name' : 'welcome_to_servicenow'},
'EXAMPLE LINE 2' : { 'name' : 'other_ui_page_name_here'},
};
}function render() {
var name = renderer.getPreferences().get("name");
var gf = new GlideForm(renderer.getGC(), name, 0);
gf.setDirect(true);
gf.setRenderProperties(renderer.getRenderProperties());
return gf.getRenderedPage();
}function getEditLink() {
if (!gs.hasRole('admin'))
return '';return "sys_ui_page.do?sysparm_query=name=" + renderer.getPreferences().get("name");
}

3) Add the widget to your homepage

Once you’ve created your widget you should be able to navigate to your homepage and select and add the widget in the same way you’ve added other widgets in the past.

Including a single-block widget

You may also want to do the same thing with only one block of the widget. For example, maybe you want a standalone chat widget for the Service Portal that you can use from a homepage. The process there is the same; just a different UI page.

<!-- Contains the HTML and CSS necessary for all styling and layout. Feel free to modify if need be. --> <style type="text/css">
    .homepage-quicklinks {<br />        background-color: #ffffff;<br />	    font-family: "SourceSansPro", Helvetica, Arial, sans-serif;<br />        font-size: 14px;<br />    }<br />	.text-info {<br />        color: #31708f;<br />    }<br />	a.text-info:hover, a.text-info:focus {<br />        color: #245269;<br />    }<br />	.text-success {<br />        color: #5cb85c;<br />    }<br />	a.text-success:hover, a.text-success:focus {<br />        color: #449d44;<br />    }<br />	.text-warning {<br />        color: #f0ad4e;<br />    }<br />	a.text-warning:hover, a.text-warning:focus {<br />        color: #ec971f;<br />    }<br />	.text-danger {<br />        color: #d9534f;<br />    }<br />    a.text-danger:hover, a.text-danger:focus {<br />        color: #c9302c;<br />    }<br />	.text-muted {<br />        color: #979797;<br />    }<br />	a.circle_icon {<br />        display: block;<br />        padding: 20px 0px 20px 70px;<br />        position: relative;<br />    }<br />	a.circle_icon .fa {<br />        position: absolute;<br />        left: 0px;<br />        top: 10px;<br />    }<br />	a.circle_icon h3 {<br />        font-weight: 300 !important;<br />        padding: 0;<br />        margin: 0 0 10px 0;<br />    }<br />	a:hover {<br />        text-decoration: none;<br />    }<br />	a:visited {<br />        text-decoration: none;<br />    }<br /></style>
<div class="homepage-quicklinks" style="background-size: initial; background-position: center center;">
<div>
<div class="row">
<div class="col-lg-6">
<div>
<div><a class="circle_icon text-danger" href="#" target="" rel="noopener">
<span class="fa fa-stack fa-2x">
<i class="fa fa-circle fa-stack-2x"></i>
<i class="fa fa-comments-o fa-stack-1x fa-inverse"></i>
</span></a>
<h3>Live Chat</h3>
<span class="text-muted">Start a chat conversation with customer service agents</span>

</div>
</div>
 

</div>
</div>
</div>
</div>

The post Service Portal-style Homepage Widgets appeared first on ServiceNow Guru.

Where does ServiceNow store bookmark information anyway???

User bookmark information is stored in the ‘Bookmark [sys_ui_bookmark]’ table which can be accessed by navigating to ‘System Definition -> Bookmarks’ in the left nav. Here you can identify bookmarks per user along with their associated settings. Included in these settings is the ability to set global bookmarks, icons, links, etc. Generally it’s much more effective to set this information directly from the simple UI provided by ServiceNow in the edge pane itself. But what if you don’t like the default icon and color used when you create a bookmark? This requires some additional intervention via the back-end table structure.

As shown in the screenshot above, ServiceNow uses a combination of icon and color shortcodes to determine the appearance of a bookmark in the UI14 edge pane. The common defaults I’ve identified include the following…

• icon-view color-green (Module link default)
• icon-book color-blue-dark (List breadcrumb/filter default)

How to adjust the default icon look for bookmarks…

These shortcodes end up getting set in the ‘icon’ field (which is hidden by default) in the bookmark record. As far as I’ve been able to tell, if you want to change the defaults set here, you need to do so using a ‘before insert’ business rule on the ‘sys_ui_bookmark’ table. A script like this can be used to make these adjustments. Simply change the icon and color shortcodes within the ‘if’ statements accordingly!

//Change default bookmark color (green) to red
if(current.icon == 'icon-view color-green'){
current.icon = 'icon-view color-red';
}//Change default bookmark color (dark blue) to orange
if(current.icon == 'icon-book color-blue-dark'){
current.icon = 'icon-book color-orange';
}

//Change default record form (red) to green and icon from form to list
if(current.icon == 'icon-form color-red'){
current.icon = 'icon-list color-green';
}

The post Modifying UI14 Bookmark Appearance and Behavior appeared first on ServiceNow Guru.

Using this little helper I put together the other day saved me some time and hassle of tracking down the table names and filters to get the right query. It’s a simple little script that makes life as an admin just a little bit easier.

To set it up in your instance go to System UI -> UI Context Menus and open a new record. The other values should be as follows:

Table: Global
Menu: List Header
Type: Action
Name: Get GlideRecord Query
Condition: gs.hasRole(‘admin’)
Order: 2000
Action script:

// Check for a query from the related list
var rel_list_prefix = '';
try{
   if(g_form != undefined){
      var field_name = g_list.getRelated().split('.')[1];
      if(field_name != undefined){
         var sys_id = g_form.getUniqueValue();
         rel_list_prefix = field_name + "=" + sys_id + "^";
      }
   }
} catch(e) {}

// Generate the query
var query = "var gr = new GlideRecord('" + g_list.getTableName() + "');\n";
query += "gr.addQuery('" + rel_list_prefix + g_list.getQuery() + "');\n";
query += "gr.query();\n";
query += "while(gr.next()) {\n";
query += " \n";
query += "}";
alert(query);

Now that you’ve got this, from any List you can right-click on the header and the bottom option will be “Get GlideRecord Query” and you can copy the resulting code. It’s nothing complicated, but can still save a bit of time.

The key to making this work is the g_list object that has the details for the list that you’re on. It’s documented fairly well on the ServiceNow Wiki and if you haven’t seen it before I’d recommend glancing at what options are available.

The post Generate a GlideRecord Query for a List appeared first on ServiceNow Guru.

While this functionality works great on standard lists, it is completely absent on related lists at the bottom of records displayed in the form view. I can’t count the number of times I wished I could export a filtered related list in the same way you can with a standard list. Fortunately, with a few slight adjustments to some context menu actions in the system, there is a way!

The Solution…

Enabling export capability for related list records in your system can be accomplished by creating some new records in the ‘System UI -> UI Context Menus’ module in your left nav. These records are based on their existing, standard list counterparts so I can show you how to add the ‘Export -XML’ option here and you can add additional options for other formats as needed. Below is the configuration setup for the ‘Export’ menu container and the ‘XML’ export menu option.

/**
* This client-side script is used to dynamically change the context menu before it is displayed.
* It is called before showing the context menu if the Run onShow script flag is checked.
*
* The following variables are available to the script:
* 'g_menu' the context menu that is about to be shown
* 'g_item' the current context menu item
* 'g_list' the GlideList2 that the script is running against (only valid for List context menus)
* 'g_fieldName' the name of the field that the context menu is running against (only valid for List context menus)
* 'g_fieldLabel' the label of the field that the context menu is running against (only valid for List context menus)
* 'g_sysId' the sys_id of the row or form that the script is running against
*//*Hide the 'Export' context menu for defined related lists
No 'query' parameter available for accurate exports*/
if(g_list.getListName().indexOf('.REL:') > -1){
g_menu.setHidden(g_item);
}

Once you’ve added the ‘Export’ menu option for related lists as shown above, you can add options for the specific types of export options within the menu. Here is the setup for the ‘XML’ export option which you can add by navigating to ‘System UI -> UI Context Menus’ in your left navigation pane. Make sure to put it under the correct Parent menu so that it shows up where you expect!

/**
* Script executed on the Client for this menu action
*
* The following variables are available to the script:
* 'g_list' the GlideList2 that the script is running against (only valid for List context menus)
* 'g_fieldName' the name of the field that the context menu is running against (only valid for List context menus)
* 'g_sysId' the sys_id of the row or form that the script is running against
* 'rowSysId' is also set to the sys_id of the row to support legacy actions, but g_sysId is preferred
*/
runContextAction();function runContextAction() {
/*Alert if context menu for defined related lists
No 'query' parameter available for accurate exports*/
if(g_list.getListName().indexOf('.REL:') > -1){
alert('Related list exports are not supported for custom defined related lists.');
return false;
}
var relField = g_list.getRelated().split(".");
var sysparm_rows = g_list.grandTotalRows;
var num_rows = parseInt(sysparm_rows);
var sysparm_query = relField[1] + "=" + gel('sys_uniqueValue').value + "^" + g_list.getQuery({orderby: true, fixed: true});var sysparm_view = g_list.view;
if (num_rows < g_export_warn_threshold) {
var dialog = new GwtPollDialog(g_list.tableName, sysparm_query, sysparm_rows, sysparm_view, 'unload_xml');
dialog.execute();
return;
}
var dialog = new GwtExportScheduleDialog(g_list.tableName, sysparm_query, sysparm_rows, sysparm_view, 'unload_xml');
dialog.execute();
}

That should be it! Once you’ve added the UI context menus, as shown above, you’ll be able to export from any related list in the system (with one exception noted below). I think that the most common use case is XML exports for admin users. If you want to enable other exports, you can combine the ‘XML’ setup provided above with the out-of-box Context menu items for CSV, XLS, or PDF.

One Exception!!!

I believe one of the reasons that this functionality isn’t included by default is that there are some related lists in the system (Defined Related Lists) that this won’t work for. The reason that Defined related Lists don’t support exports is that they don’t include a query/filter component that you can get to via the context menu. Because of this, you’ll end up exporting all of the records in the table instead of the filtered related list.

I’ve included checks in the UI Context Menu records above to disable this functionality on defined related lists in your system. While these types of lists are extremely useful they’re also much less common so it isn’t much of an issue. Here are a couple of links to help you understand more about Defined Related Lists in ServiceNow.

https://servicenowguru.com/system-definition/relationships/defined-related-lists/
http://wiki.servicenow.com/index.php?title=Creating_Defined_Related_Lists

The post Enabling Related List Exports in ServiceNow appeared first on ServiceNow Guru.

The first step to making this work is to define your style sheet as shown in the screenshot above. What I’ve done is obviously just an example and you can customize this however you want. Style sheets can be defined under the ‘Content Management’ application in your left navigation toolbar.

Next, right-click the style sheet record header and copy the sys_id value. You’ll need the sys_id in order to tell the system which style sheet to use.

Now comes the tricky part. You need to determine where to add the link to your style sheet. In the knowledge base example, there are a couple of options. The first is simply to place the following html tag into your article text field while in the HTML code view (where the ‘href’ attribute includes the sys_id for your CMSstyle sheet record).

Shannon’s idea was to leverage the ‘kb_view_custom’ UI macro to include the style sheet link in one place for all articles. You can do this by creating or modifying the ‘kb_view_custom’ UI macro under ‘System UI -> UI macros’ to include the same code as shown above (where the ‘href’ attribute includes the sys_id for your CMS style sheet record).

Here’s one example of what this might look like…

The post Custom CSS style sheets in non-CMS pages appeared first on ServiceNow Guru.

The following methods are designed for use in client-side scripting (primarily client scripts and UI policies). As such, they are used on standard forms and on catalog forms and can run on load or submit of a form, or on change of a field value.

Function/Method	Description	Usage
addInfoMessage(message)	Displays an informational message at the top of the form with a blue information icon and a light-blue background.	g_form.addInfoMessage('Form Info Message Text');
addErrorMessage(message)	Displays an error message at the top of the form with a red error icon and a light-red background.	g_form.addErrorMessage('Form Error Message Text');
clearOutputMessages	Hides ALL form info and error messages. There is no way to remove form info and error messages individually.	GlideUI.get().clearOutputMessages();
showFieldMsg(input, message, type, [scrollForm])	Displays either an informational or error message under the specified form field (either a control object or the name of the field). Type may be either "info" or "error." If the control or field is currently scrolled off the screen, it will be scrolled to. A global property (glide.ui.scroll_to_message_field) is available that controls automatic message scrolling when the form field is offscreen (scrolls the form to the control or field). Optional: Set scrollForm to false to prevent scrolling to the field message offscreen. Parameters: input - specifies the name of the field or control. message - the message to be displayed. type - error or info. scrollForm (optional) - true to scroll to message if offscreen, false to prevent this scrolling.	//Field info message g_form.showFieldMsg('priority','Priority is low.','info'); //Field error message g_form.showFieldMsg('impact','Priority is high!','error');
hideFieldMsg(input, [clearAll])	Hides info and error messages for a single field.	g_form.hideFieldMsg('impact', true);
hideAllFieldMsgs([type])	Hides all field info and error messages. Optional: Provide type to hide only "info" or "error" messages.	g_form.hideAllFieldMsgs();
flash(widgetName, color, count)	Flashes the specified color the specified number of times in the field. Parameters: widgetName - Specifies the element with (table name).(fieldname). color - RGB or CSS color count - How long the label will flash. use 2 for a 1-second flash use 0 for a 2-second flash use -2 for a 3-second flash use -4 for a 4-second flash	g_form.flash("incident.number", "#CC0000", -2);

Server-side UI Messages

Although messages will always be displayed client-side, they are often initiated from a server-side script like a business rule, record producer script, or script include. Messages initiated from server-side scripts can appear at the top of any form or list and are typically triggered by a database action such as a record insert, update, or delete.

Function/Method	Description	Usage
addInfoMessage(message)	Displays an informational message for the current session with a blue information icon and a light-blue background. Can also include HTML in the message! Note that I've replaced the greater than and less than symbols with brackets in the HTML usage example to get it to display correctly here. You'll need to change the brackets back to standard HTML to get it to work in your instance.	gs.addInfoMessage('Session Info Message Text'); //Info message with HTML formatting //Create the html contents of the information message var link = '[a href="incident.do?sys_id=' + current.sys_id + '" class="breadcrumb" ]' + current.number + '[/a]'; var message = 'Incident ' + link + ' has been created. '; message += 'Thank you for your submission.'; //Add the information message gs.addInfoMessage(message);
addErrorMessage(message)	Displays an error message for the current session with a red error icon and a light-red background. Can also include HTML in the message!	gs.addErrorMessage('Session Error Message Text');
flushMessages()	Clears any existing session info or error messages to prevent them from being displayed.	//Clear any session info or error messages gs.flushMessages();

UI Notifications

UI Notifications are an unusual class that can be used for refreshing elements such as the navigation pane or for displaying messages in response to changes in database tables. For more information about UI Notifications, check out the following articles:

• Refresh the Left Navigation Pane via Script
• Display Messages With UI Notifications

The post UI Info and Error Message Cheat Sheet appeared first on ServiceNow Guru.

1) Install the ServiceNow Guru ‘Module Counts’ update set

The ‘Module Counts’ update set is what makes this whole solution work. By installing the update set you can set up a module in your left navigator that updates automatically as new entries come into your chat queue. You can access the download directly from this link.

2) Configure the ‘Waiting Chats’ module

Once you’ve committed the ‘Module Counts’ update set you can create the module to display the number of waiting chat queue entries. I placed my module under the ‘Service Desk’ application and configured it as shown in the screenshot below…

3) Configure the ‘Waiting Chats’ list layout

Once the module is configured, you should see the ‘Waiting Chats’ record count displayed in next to the module in the left navigator. You’ll also want to personalize the list layout and list control to show the correct information. I changed the columns and removed the ‘New’ button. You can perform these actions by right-clicking the list header and selecting ‘Personalize’.

4) Add a ‘Show Chat Desktop’ UI action to your list

Finally, you can add a context menu UI action for your list so that technicians can click into the module, right-click one of the entries, and open up the chat desktop directly from the list.

Here’s how I set up the UI action…

// Show the chat desktop in a new window
function showChatDesktop() {
var url = 'chat_desktop.do?sysparm_nostack=true';
window.open(url, 'chat_desktop');
}

That’s it! Hopefully this solution gives you a better way to manage your chat queue going forward.

The post Waiting Chat Queue Entries Notification appeared first on ServiceNow Guru.