Auto Numbering – snhackery

“Every new beginning comes from other beginning’s end.”
— Lucius Annaeus Seneca

Last time, we laid out the basic concept for this little project and today it’s time to get to work. To begin, we need to create a new Scoped Application that we will call Periodic Review. It’s a process that we have done here many times before, so there is no need to waste time going over that again, but here is a screenshot of our new application.

*New Periodic Review application record*

Now that we have our application defined, we should probably set up a few properties so that it can be easily configured for different implementations. A few years back, we implemented a tool just for that purpose, so let’s click on that little Setup Properties button and get things started. Once that has been done, you will see that the button no longer appears, and we can use the System Properties tab to start adding properties via the New button.

*Application with system properties set up*

For now, let’s just add a few things that we can think of right at the moment, and if we need more we can circle back add additional properties at a later time.

*New properties added to the application*

The purpose of each of these properties will become clear once we get into things, but for now, it’s enough to know that they exist. You will also notice a new action item above the list called Manage Application Properties. That will take you to the admin screen where you can adjust the values.

With that out of the way, we can start building our tables. We will need a few of them, but let’s start out with the basic configuration record for each implementation of the review process. The assumption here is that each implementation of the review process will review a specific artifact, and that artifact is maintained in another table in the Service Now instance. For example, if wanted to implement the review process for our recent Service Account application, the referenced table would be the Service Account table in that application. So one of the important fields on this table will be the table that contains the items to be reviewed. Other fields on the table will need to define the configuration for reviewing the item in question, and they may evolve over time as we work our way through the development, but let’s begin with what we envision so far.

We will want to number these records, as so many things are in the Now Platform so we will need a field called number and we will need to set up the numbering, which we have also done before. Next would be the name of the table, and then we will need a few fields that will tell us where to find certain things on that particular table.

Recipient column – The name of the column containing the person to be notified
Escalation recipient column – The name of the column containing the person to be notified if the original recipient does not take action in a timely manner
Short description column – The name of the column that contains a brief description of the item to be reviewed
Description column – The name of the column that describes the details item to be reviewed

In addition to the details about the subject table, we will also need a little more information about this particular implementation of the review process.

Short description – The common name of the review process
Description column – A more detailed description of the review process
Item label – How do we refer to the items being reviewed
Frequency – How often to we run the review process for these items
Filter – An encoded query filter for the specified table that the process will use to select the items up for review
Next scheduled date – The date of the next run
Action page header – Optional text to be included at the top of the page where the responsible person will indicate the appropriate action for each item listed
Response page content – Optional text to be included on the page presented when all of the appropriate actions have been submitted
Resolution Script – A reference to a Script Include that will run to process the actions requested
Resolution Subflow -A reference to a Subflow that will run to process the actions requested (if both a script and a flow have been specified, only the script will run)
Fallback recipient – A reference to the User table for a person to receive the notices if the designated recipient field is empty or if that user has no email address

One other thing that we will need is some text for all of the possible notices that might go out, including the original notice, a reminder notice if no action has been taken after a specified period, and possibly even an escalation notice to go to some higher authority if there is still no action. To accommodate those needs will need to add the following fields.

Notice header
Notice subject
Reminder header
Reminder subject
Escalation header
Escalation subject

That should complete our first table for our new application.

Before we jump into the next table, we should probably organize the layout of both the form and the list, and also take care of any policies and actions that we might want on the form. Since that’s probably a little bit of work, let’s jump into that next time out.

“Well done is better than well said.”
— Benjamin Franklin

Now that we have the idea fairly well formulated, it’s time to get to work. The first thing that we need to do is create our Scoped Application, which you can do by navigating to My Company Applications and then clicking on the Create new button in the upper right-hand corner. I still use the classic UI rather than the Studio, so you may approach this task a little differently, but the end result should be the same.

At this point, I have just created the most basic of empty shells. There are no modules or tables or roles or any other artifacts … it’s basically just the bare application record itself. Creating the app does create a scope, and also puts you into that scope, so as long as you don’t change that, everything that you do from this point on will be built in that scope. The first thing that we will want to build is the database table for our registry, which we can do by navigating to System Definition -> Tables and clicking on the New button.

Once you give it a Label it will generate the appropriate name, and the next thing that you are going to want to do is to uncheck the Create module option, as we only want the table at this point and we don’t need all of those other artifacts generated. We want to give our registrations an ID using the platform’s built-in tools, so we will want to create a field labeled Number of type String and put the following in the Default value:

javascript:getNextObjNumberPadded();

We have a number of other columns to define, but let’s save this for now and go set up our auto-numbering before we forget. To do that, navigate to System Definition -> Number Maintenance and click on the New button. Select our new table from the list and then let’s set the Prefix to WHR for Webhook Registry,

*Setting up auto-numbering for our new Webhook Registry table*

With that out of the way, we can go back to our table and add the rest of the fields. Here are the ones that I added to get things started:

Active – True/False, with default of True
Table – Table Name, with default of incident
Owner – Reference to the sys_user table
Type – String, with four initial choices (Single Item, Caller / Requester, Assignment Group, and Assignee)
URL – URL
Authentication – String, with two initial choices (None and Basic)
User Name – String
Password – Password
Document ID – Document ID
Person – Reference to the sys_user table
Group – Reference to the sys_user_group table

We may add a few more later on as we add new features, but this will get us by for now. Event though my intent is to focus solely on the Incident table for now, I went ahead and added the Table column and just defaulted it to Incident. That was mainly so that I could use as the Dependent field on the Document ID field. If you have never worked with Document ID fields before, you can just think of them as a special form of Reference field where you don’t have to specify the table that is being referenced. Instead, you point to another field on the record that contains the name of the table. This way, one of your records can reference one table and another record in that same table can reference a different table, all based on the table specified in the Dependent field. To set up the Dependent field, use the Dependent Field tab on the Dictionary Entry for the Document ID field.

*Document ID Dependent field specification*

After entering all of the fields, I used the Show form link at the bottom of the page to bring up the form for the new table. Using the Configure -> Form Layout option, I rearranged the fields on the screen to my liking, and then removed the Table field completely, as that will default to Incident for now and we don’t want anyone changing it to anything else at this point.

After getting everything laid out just right, the next thing that I did was to add a few UI Policies to control certain fields based on the value in other fields. For example, I hide the User Name and Password fields unless you set the Authentication to Basic. Similarly, the presence of the Document ID, Group, and Person fields are all dependent on the value of the Type field. Basically, this just hides fields that are not needed and reveals them when they are.

The other things that I wanted to do on this form was to give the user the ability to test their URL. That seemed like a good use for a new UI Action, but rather than putting all of the code for that process in the Action itself, I decided to start a Script Include to house these types of utilitarian functions. Putting all of that together seems like a good exercise for our next installment in this series, so this looks like a good stopping point for now.

Tag: Auto Numbering

Periodic Review, Part II

Fun with Webhooks, Part II

Useful ServiceNow links:
Main web site:	https://servicenow.com
Developer site:	https://developer.servicenow.com
Annual Conference:	https://knowledge.servicenow.com