“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.
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.
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.
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.
