It is that time again in the ServiceNow year, new release Early Access season! The Kingston release has just become available to the Personal Developer Instances. If you are eagerly awaiting the new features, you can now upgrade and take them for a test drive.
In another post, josh.nerius covered one of the primary features of interest to developers in this release: Flow Designer and IntegrationHub. I am going to provide a survey of some of the other topics.
SQL Function Fields
New to the platform in the Kingston release are Function fields. This exposes some of the capability of database calculations up through the ServiceNow interface, allowing you to act on derived values in the same way as you would fields of the record. For example, you can now use operators like length() and concat() on String values, or datediff() on DateTime values.B
Dictionary Entries can be configured to use these functions. There is a checkbox on the form now to specific that the value is in fact a Function Definition rather than a static value so it will be computed at runtime. Where this differs from calculated fields is that these results are always dynamic and never stored in the database. They don’t need to be maintained and altered when data changes, they are calculated new every time.
Because these same functions can be used in scripting as well, this increases the power available when querying and manipulating records from scripting. This allows for things like querying on these derived values. One could also order by the difference between two DateTime fields, for example, to find the records with the shortest or longest resolution times.B
In Kingston, a user has the ability to set their email notification preferences to digest. This allows you to group into one email all the notifications that you may not wish to receive individual emails about, similarly to how one might deal with a chatty email group. From the developer end, when defining a Notification and formatting what it will look like, you have a checkbox to Allow Digest. Enabling that will display the “What Digest will contain” tab in which you define the parameters of the digest email much like the Notification itself. You choose the subject for the email itself and then what each entry of the digest will contain. All of these allow the same templating replacement that you are used to in Notifications. This allows you to reduce the amount of email traffic, especially for those messages that don’t require immediate action.B B
Connections and Credential Aliasing
As of Kingston, you can now avoid hardcoding URLs and username/password combinations in logic and records. This is always problematic as these will typically differ amongst development, test and production environments. In Kingston you can define a Connection and Credential Alias. You will use this Alias where you previously used a Credential record and at runtime it will look for the value defined on the present system for that Alias value. This abstracts away the Credential one step and reduces the risk of using the wrong system in an environment. It is philosophically similar to using System Properties to abstract away specific hardcoded values. In this case, it is a first class record of the platform.B
Machine learning is a big topic in the software world currently. With the introduction of the Agent Intelligence capability to ServiceNow, it is possible to apply that to your own applications. The one big caveat here is that as of this writing this capability will *not* be available in the Personal Developer Instances. For customer instances on Kingston it will be available but not yet for PDI. This function requires a whole new set of infrastructure to do the very intensive data crunching required and for the time being those resources are being focused on customers. We will let the developers know when this functionality becomes available for PDI.
Agent Intelligence allows you to configure a learning algorithm to predict values in records based on previous data. Given this definition, your instance passes the historical records that match your filter to the training server, where it crunches it down into a final set of machine instructions. Given this solution, you can then pass input through that and get predicted outputs. Some common examples of use cases include using the Short Description field of your common ITIL records like Incident/Problem/Change and generating a predicted Assignment Group and/or Category from that data. Ultimately the goal is to shift the routine work that doesn’t create value to the robots, freeing up the humans to do the work machines cannot. Welcome to our infotopia future!
That is the high level description. Let’s look in a little depth about how this works.
To create a Solution Definition, you configure a few values.
- Source Table
- Filter defining records to include in the training set
- Input fields to serve as input into the training algorithm.
- The final output field
To work best, the output field needs to have a constrained set of possible values. This works well with Choice List type fields such as Category/Impact or reference fields like Assignment Group. Like all machine learning, the better and the larger the training set, the better the quality of the predictions generated by the algorithm.B
When defining the Solution Definition, you can configure a retraining period so that a new solution can be trained automatically at an interval that makes sense for your organization. As seen in the example below, you would typically limit the training set by time so that you can maintain some chronological relevance. The training set is defined with standard ServiceNow filters so any set you can query down to can be the input to the training algorithm. Typically you would be training on the data that has reached a final state so that any changes to it during its lifecycle would be incorporated. If you trained on data in flight, you can’t guarantee that the record isn’t reassigned to another group before it gets resolved. The goal is to have the training data incorporate every decision that has occurred in the life of that record because those decisions are what you are aiming to replicate.
In the Solution, you can define the confidence level that will specify an acceptable confidence level per class. When generatingB predictions, it will only provide values for which the prediction confidence meets or exceeds this level. In this same configuration area, you can choose to exclude some classes from any predictions.B
Once the training set has been generated, what exactly do we do to use these predicted values? There is a OOB Business Rule named “Default Incident Based Prediction” that serves as a good example. This rule will loop through every active Solution available for the current record and for each of those look up the predicted value. It looks to see if the value passed into the record differs from default (meaning the user directly specified it) and if not, it will set the predicted value for that field. Along with that, it adds a note to the addInfoMessage function about which fields were set to predicted values automatically so that this will echo back to the user.
This Business Rule is a good model for developers looking to replicate this kind of functionality in their own applications. It is a good practice to inform the user when these values are set by the system automatically to make it explicit. As mentioned previously, the confidence level is configured into the Solution so if a prediction is being provided to the logic of the Business Rule, it has already passed that confidence check and can be assumed to be high enough probability to use. For the small fraction for which the prediction get amended before resolution, that will feed back into the next training set. In this way, the quality of the predictions should always be increasing over time.B
Kingston is an exciting release from the developer perspective. There are many features to sink ones teeth into. Kingston is already available for upgrade in the Personal Developer Instances so feel free to explore away. Happy developing!