November 2022 – snhackery

Service Account Management, Part VI

Posted on November 30, 2022 | by snhackery

“Never discourage anyone who continually makes progress, no matter how slow.”
— Plato

Last time, we built out a fulfillment Subflow for one of our two example Service Account types, so now we can build the primary Flow that will call that Subflow and do all of the other work required to fulfill the request. Although you can configure a Flow to call a Subflow using the Flow Designer, you have to specify the Subflow during the development process. In our case, the Subflow that we will want to use will be dependent on the type of Service Account requested, so we will not know which Subflow will need to be called until execution time. Ideally, we would want to look the type requested, read the record for that type to get the Subflow, and then execute the Subflow specified in the type record. Since there doesn’t seem to be a way to do that out of the box, we will need to build out a custom Action to make the Subflow call via script. I created a simple Action called Create Service Account that takes the name of the Subflow and the Requested Item record as input and returns the same outputs as our fulfillment Subflows. The script for that Action looks like this:

(function execute(inputs, outputs) {
	try {
        var result = sn_fd.FlowAPI.getRunner()
            .subflow(inputs.subflow)
            .inForeground()
            .withInputs({requested_item: inputs.requested_item})
            .run();
		var returned = result.getOutputs();
		for (var name in returned) {
			outputs[name] = returned[name];
        }
    } catch (e) {
        outputs.success = false;
		outputs.failure_reason = 'Subflow execution failed with error: ' + e.getMessage();
    }
})(inputs, outputs);

All it does is launch the Subflow with the Requested Item record passed and returns whatever is returned by the called Subflow. This will essentially perform the same function as the Call Subflow action, but with the added benefit of allowing us to pass in the name of the Subflow to be called rather than have it hard-coded in the Flow.

Now that we have the ability to call a configured Subflow, we can jump back into the App Engine Studio and build out the primary Flow. On the dashboard for our application, we can scroll down to the Logic and automation section and then click on the Add button right after the section header.

*To create a new Flow, click on the Add button near the Logic and automation section header*

Once you click on the Add button, a selection list appears, with Flow being the first option.

On this screen, we simply select Flow from the available options, which takes us to the next screen.

On this screen we enter Service Account Request Fulfillment in both the Name and the Description fields and then click on the Continue button.

The next screen just comes up long enough for the basic Flow to be created, after which we are brought to the successful completion screen.

At this point, the Flow now exists, but it has no steps, so we will want to click on that Edit this flow button to start building out the logic of the Flow. We will select Service Catalog as the trigger, and as we did with our sample Subflow, the first thing that we will want to do is to gather up the variable values from the Requested Item.

*Grabbing the variable values from the Requested Item*

This time, we will need the type, the responsible_group, and the account_id from the request. The next thing that we will want to do is to read the Service Account Type record for the requested type, so we will select Look Up Record for our action.

*Fetching the Service Account Type record*

We are looking for the record where the Name field matches the type selected on the Catalog Request. Once we have the variable values from the request and the matching type record, we can call our type-specific Subflow using the Action that we created for that purpose.

*Creating the Service Account using the type-specific Subflow*

Now we need to check to make sure that the account was created, so we add an If condition based on the success flag returned by the Subflow.

If the account was created successfully, we will want to create a record for the account in our Service Account table, but before we can do that we need to fetch the record for the responsible group from the sys_user_group table. We have the name of the group from the catalog item variables, but we need the sys_id of the record to populate the Service Account record. We can do this with another Look Up Record action, searching the table for a record with the same name.

With the user group record now in hand, we have enough information to create the new record in our Service Account table.

*Creating the new Service Account table record*

Once we have created a record for the new Service Account, we will want to inform the user that the account has been created and is available for use. I took a short-cut here and just stubbed out a simple email, but ideally you would want to use a mail template and include some boiler-plate verbiage about company policies on the use of Service Accounts, security concerns, and related information on the owner’s responsibilities. All of that would ultimately be up to anyone attempting to implement such as system, and has little relevance to the workings of the process, so I will leave that to others and just include something simple as an example.

*Informing the user of the account’s availability*

The password for the account should be sent out in a separate email, but before we do that, let’s go ahead and close the Requested Item now that the account has been created and the requested notified. To do that, we will select Update Record for our action and then drag in the pill for the Requested Item record, which will then populate the Table value.

Now all that is left to do is to send the password for the account to the requester. I took another short-cut here in that the only contents of the body of the email is the password itself with no other information, but again, this is only a sample. An encrypted email from a template would obviously be preferable here, but this at least provides a placeholder for performing this task in a much better way.

That completes the process for a successful account creation, but if the account could not be created for any reason, we still need to close out the Requested Item with that information. To do that, we will add an Else condition to our If and then insert one more step under the Else.

*Closing the Requested Item on account creation failure*

And that’s all there is to that. Now that we have our completed Flow, we can go back into our Catalog Item and specify this Flow for fulfillment. Once that has been done, we can finally request the item to generate a Requested Item record that we can use to test all of this out. That will probably be a little bit of an adventure, so let’s save all of that for our next time out.

Service Account Management, Part V

Posted on November 28, 2022 | by snhackery

“One step at a time is all it takes to get you there.”
— Emily Dickinson

Last time, we built out the majority of the Catalog Item that we are creating for the purpose of requesting a new Service Account. All that is left for us to do now is to create the process that will fulfill the request once it has been made. Because our intent is to create a single Catalog Item for any type of account, and each type of account will have its own unique account creation process, we will want to build a generic workflow of some kind that will look at the type requested and then launch the appropriate fulfillment process based on that type. Before we jump in and start creating things, though, we will need to come up with a strategy that will facilitate combining a generic outer process with a type-specific inner process.

Assuming that each type will have its own Subflow unique to the type, we will want to store a link to that Subflow on the type record that we created earlier. This way, the generic process can look at the type requested, read the record for that type, and then grab the link to the Subflow so that it can be launched. To make that work, we will need to devise some kind of standard for the Subflow in terms of inputs and outputs so that the generic process can consistently communicate with any given fulfillment Subflow. For input, the Requested Item record should suffice, but the outputs will depend on how much work will be delegated to the Subflow and how much will be handled by the primary process.

In addition to the creation of the account, our process should also perform a number of other tasks such as notifying the user of the account’s creation, sending them the assigned password, creating the record in the accounts table, and closing the request. Since everything except the account creation is universal, our Subflow should be limited to just the steps necessary to create the account, and all other activities should be handled by the primary request. For that to work, the Subflow will need to return sufficient data to the primary process so that it can successfully complete all of the other work. We also have to allow for the possibility that the account could not be created for whatever reason, and that information will need to be communicated back as well. This may change over time as we get into the weeds, but for now, I think that the following should be able to handle everything needed.

Success flag
Failure Reason
Account ID
Account Password
Account Owner Instructions

Since we will need a working Subflow to test out the primary process, it might be wise to start with that first, and then circle back to the primary process once we have a working Subflow to call. Before we do that, though, we need to figure out a way to generate a password. If you search through all of the Script Includes bundled with the product for anything that has the word password in the name, you can find a lot of password generation scripts already out there. Unfortunately, these are all in the global scope, and their access is limited to the global scope, so we can’t call any of these from our Scoped Application. If you search the Internet for password generation scripts, you can find even more, but most of these are much more sophisticated that I was looking for. Ultimately, I borrowed a few things from here and there and came up with a simple Action that had no inputs, one output, and a single script execution step with the following logic.

(function execute(inputs, outputs) {
	var upper = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ';
	var lower = 'abcdefghijklmnopqrstuvwxyz';
	var number = '0123456789';
	var special = '!@#$%&*()_+<>[].~';
	var source = upper + lower + number + special;
	outputs.password = '';
	while (outputs.password.length < 32) {
		outputs.password += source.charAt(Math.floor(Math.random() * (source.length + 1)));
    }
})(inputs, outputs);

This does not guarantee that you will have at least one of each category of character, but with 32 positions, the chances are still pretty good that you will. I ran it a few times to see, and I didn’t think that the results looked all that bad.

dPoxtBDUqaCtFaH2knI]XI0Ts*#1rKyT
xnDRzngKOMy~py8xK[xV]2S2CTkh]RWv
knUHn*0WJ4H_Ww90gq[2TqJmKKb0Xu9v
OcWe4TKQN#0[RM1wj$p$(#_Sp.~CVTiM
>wEE!CbrFGwYccWb#H>+6pyEpZwjcJ%A

Each one seems to have a little bit of everything, so I think it is good enough for what we are trying to do here. So now that we have that in place, we can start working on our Subflow. Unfortunately, you can build a Flow in the App Engine Studio, but not a Subflow (or at least if you can, I cannot figure out how to do that). So, to build out our Subflow, we will have to jump into the old Flow Designer. To create a new Subflow, we select New -> Subflow up in the upper right-hand corner and give it a name of ServiceNow Service Account Creation. The first thing that we will do is create all of the inputs and outputs listed above.

Once we have our inputs and outputs defined, we can jump down in the Actions section and start adding steps to the flow. The first thing that we will want to do is to grab the requested account ID from the Requested Item, so we will select Get Catalog Variables from the list of available actions and drag in the Requested Item pill from the inputs.

*Fetching the account ID from the Requested Item*

For the template, we select our new Service Account Catalog Item, and once we do that, all of the variables defined for that item appear in the Available list, from which we can select account_id. This will give us an account_id pill which we can use in future steps.

The next thing that we will want to do is to find out if the requested account ID is already in use. We can do that by reading the sys_user table, so for our next step we select Look Up Record from the list of actions and select the User table from the list of tables.

*Checking the sys_user table for an existing account*

Our only condition for this is that the User ID is the requested account ID, which we again drag over from the inputs. Once we attempt to fetch the record, the next thing that we will want to do is to check and see if a record was returned, so for our next step we will select If from the Flow Logic options.

*Checking to see if a record was found on the sys_user table*

If a record was returned with the requested account ID, then we want to stop the process and return a failure message back to the calling Flow. To do that, we select Assign Subflow Outputs for our next step and fill in the values for the output fields.

*Setting the Subflow outputs for existing User ID failure*

Hopefully, the account will not already exist, so we will want to put all of our other steps under an Else condition. The first step under our Else condition will be to generate the password using the Action that we created earlier.

Once we generate the password we have enough data to create the user record, so for our next step we will select Create Record from the list of actions and populate the record with data pills from the input and preceding processes.

*Creating the new Service Account record*

Once the record has been created, we need to report back to the calling Flow, so once again we will select Assign Subflow Outputs and populate the appropriate fields.

*Setting the Subflow outputs for successful completion*

Now all we need to do is to Save and Publish our Subflow and we will have one example to use for testing. We will still need to create one more for our other example use case, but we won’t need to do that just yet. Let’s see if we can make all of this work with our first example before we run off and build another.

At this point, it would be good to test this out to make sure that it all works, but to do that we will need a valid Requested Item record to send in as input, and since we have not completed our Catalog Item, we can’t really do that just yet. Let’s build our primary Flow first, and then update the Catalog Item to point to that Flow, and then we can publish the item and do some testing. To build the Flow, we can go back into the App Engine Studio, so let’s dive into that next time out.

Service Account Management, Part IV

Posted on November 18, 2022 | by snhackery

“For the things we have to learn before we can do them, we learn by doing them.”
— Aristotle

Last time, we finished up our two data tables and got started on the Catalog Item that people will use to request a Service Account. Today we need to jump back into the App Engine Studio and complete the work on that Catalog Item. To begin, we can pull up the dashboard for our Scoped Application and select our new Catalog Item from the list of Experiences.

*Selecting the Catalog Item from the list of Experiences*

Once we select our Catalog Item, a new tab opens up with all of the details.

Here we can see that there is quite a lot more detail that we can add, but before we start exploring all of the links on the right-hand side, let’s go ahead and scroll down and complete the information for the Item details section.

For now, we will just use the same image that we used for the app itself and the same text as the Short Description that we entered earlier. We may improve all of that later on, but this will get us going for now. At this point, we can click on the Continue to Location -> link.

Here we can specify that we want the item in the Technical Catalog and assign it to the Services category. Then we will click on the Continue to Questions -> link to move on to the next section.

Questions are the means through which we collect information from the requester about their request. For our purpose, we will need to know the type of account requested, the desired user ID or account name, and the name of the group that will be responsible for the account. For the benefit of the request approvers, we may also want to collect the purpose of the account or the justification for its creation. We can add these questions, one at a time, but clicking on the Insert new question button.

On the Question insert screens, we can define a name and a label for our question as well as type, which in our case will be a choice list from our Service Account Type table. You can see the two options that we added to the table come up on the drop-down list in the Question Preview section. We can Save this Question and continue to add more Questions using the Insert new question button. When we are all through adding our questions, they appear on the list.

Once we have completed all of the Questions for our item, the next step is to move on to the Settings section.

Here we select the label for the submit button and check a few boxes to configure how our item will appear on the Service Portal. Once that is done, we move on to the Access section.

Here, we make our item available to admins, ITIL users, and the Service Desk. Once that has been established, we move on to the Fulfillment section.

Here we need to select the fulfillment flow that will be used to respond to the request. We have not yet built out a fulfillment flow for our Catalog Item, so we will need to do that first before we can complete this section. Once it has been completed, we can circle back and select it from the list to complete this section, after which the only thing left to do will be to go to the final Review and Submit section. Creating a flow that will handle all of the various types of Service Accounts will be a bit of work in and of itself, so let’s stop here for now and jump right into that next time out.

Service Account Management, Part III

Posted on November 15, 2022 | by snhackery

“March on. Do not tarry. To go forward is to move toward perfection. March on, and fear not the thorns, or the sharp stones on life’s path.”
— Kahlil Gibran

Last time, we jumped into the App Engine Studio and began the process of creating our new Service Account Management app. We created the app and the two tables and now we need to edit the tables to add fields. We won’t necessarily add all of the fields that we need right now, as we don’t know exactly what we will be needing to support all of the processes just yet, but we will add enough to get things started. To begin, let’s jump back into the studio and pull up the dashboard for our new Scoped Application.

*Service Account Management app dashboard*

Let’s start with the Service Account table by clicking on the ellipses at the end of the row and select the Edit option. That brings up a series of modal help screens that we need to click through to get to where we can actually add a new field.

The first field that we want to add is the reference to our type table, so we give it a label, which generates a name, and then we select Reference from the available field types.

Selecting Reference from the drop-down opens up yet another pick list, which is a list of tables from which we will select our Service Account Type table.

*Service Account Type field added to Service Account table*

Now that we have added the type field to our table, we can use the same procedure add additional fields. For now, we will just add the fields that we think that we will need to support our processes, and then add more later if we find that other data points are needed. At this point, we will just include the following:

Active Flag
Account User ID/Name
Owner
Owning Group
Provisioned Date
Retired Date
Last Attestation Date
Last Attested By

Other things that we might need could possibly include a link to the Requested Item that created the account or the workflow that created the account, but let’s set those ideas aside for now and just focus on the basics. Here is the complete table definition after adding all of the fields.

Now we need to do the same thing for our technology type table, which will have even fewer fields.

That completes the work on the tables for now, but before we move on, let’s add a couple of rows to our type table for the two types of examples that we will use for testing, one that can be fulfilled through automation and another that we will fulfill manually. For the automated example, we can simply use ServiceNow Service Accounts, and for the manual example, let’s do Active Directory. To begin entering data from the App Engine Studio, pull up the dashboard for the app and select the PREVIEW link for the desired table.

This will bring up an empty list of records for this new table where you can click on the New button to bring up the data entry form.

Once we enter all of the data for our two example types, we are returned to the list view where we can see our two new records.

Now that we have our tables and control data in place, we can turn our attention to the process of requesting a new service account and fulfilling that request. Requests for new Service Accounts will be made through the Service Catalog, so we will need to build a new Catalog Item for these requests. In the App Engine Studio, a Catalog Item is a type of Experience, so to create a new Catalog Item, we will click on the Add button in the Experience section header.

*Adding a new Experience from the dashboard*

This brings up the Experience type selection screen where we will select Catalog Item from the available options.

*Selecting Standard catalog item from the choices presented*

This brings up a splash screen where we have to scroll down and click on the Begin button.

*Initial splash screen for building a new Catalog Item*

After clicking on Begin, we can enter the details for our new Catalog Item.

Once you enter all of the requested data and click on the Continue button, the new Catalog Item is created.

After you sit and watch that screen for a bit, you are eventually taken to the completion screen.

Of course, that’s not all there is to a Catalog Item. We will need to collect some data from the requester, including things like the type of Service Account requested and the desired user ID. Also, we will need to build some kind of fulfillment workflow that will get the account created. Next time, we will hit that Edit catalog item button and see if we can take care of all of that.

Service Account Management, Part II

Posted on November 11, 2022 | by snhackery

“It is not the most intellectual of the species that survives; it is not the strongest that survives; but the species that survives is the one that is able best to adapt and adjust to the changing environment in which it finds itself.”
— Charles Darwin

Last time, we introduced the idea of building a simple little app to manage Service Accounts. Today, we are going to jump into the App Engine Studio and see if we can throw something together using that tool. To be completely honest, I have been more than a little resistant to try doing anything with that tool since it first came out, mainly because I am quite comfortable with (and quite productive) doing things the way that I always have, and quite frankly, I never really understood the benefit. Still, it’s what all of the cool kids are doing these days, so what the heck … let’s give it a shot.

To begin, let’s click on that big Let’s Go button on the initial splash screen, and then click on the Create App button up in the top corner of the App Engine Studio home page.

On this initial app creation screen we can enter the name of our app, a brief description, and upload an image that we snagged from someone else’s web side. Then we can hit that Continue button and see what comes next.

*Second step of the app creation process*

The default roles that were generated by the process seem to be sufficient for now, so let’s just click that Continue button again and see what’s next.

At this point, it looks like it has enough information to actually create the artifacts for the app, so we will watch this screen for a bit before it automatically jumps into the next page.

*Final screen in the app creation process*

At this point, we are done with the initial app creation, so the only thing left to is to click on the Go to app dashboard button to continue working on developing the app.

From here, it looks like we can do all kinds of things, but the first thing that we need to do is to create our tables, so let’s click on the Add link next to the word Data.

This brings up a couple of choices, and since we don’t have any data to import, we want to select the first option and create a new table.

There is not much to do here on this screen, so we will just click o the Begin button to continue.

*Table creation method selection screen*

Now we are presented with a few options, but again we have no external source for our data and the entire thing will be net new, so let’s select the Create from scratch option and Continue.

Now we are at a point where we can name our new table and set up the auto numbering for our records. The first table that we want to build is the master table of accounts, so we will call it Service Account, and give it a number prefix of SA. Once we complete the form, we can click on the Continue button to proceed.

This gets us to the permissions settings, and for now, let’s give all permissions to everyone, and then click on the Continue button.

After watching this screen for a bit we are finally taken to this screen, completing the table creation process.

At this point, our new table is created. We have not defined any fields as yet, but every ServiceNow table gets a set of stock fields, and since we set up auto numbering, we will get a number field as well. The rest will obviously have to be done after the creation of the table. One of those new fields, however, will be a reference field pointing to our new technology type control table. That table has yet to be created though, so before we start adding fields to our account master table, we should probably repeat this exercise for the control table. There is no point in going through the entire exercise, but here is the screen shot with the relevant information for our second table.

Now that we have created both of our new tables, we can start defining all of the fields, including the reference field that defines the relationship between the two. That’s probably a bit of work in and of itself, so let’s save all of that for our next installment.

Service Account Management

Posted on November 8, 2022 | by snhackery

“Ideas won’t keep. Something must be done about them.”
— Alfred North Whitehead

As most of you are aware, a Service Account is a special kind of user account that does not actually represent a physical human being. Most user accounts are for real users, but for automated interfaces and other integrations, many times you need credentials on external systems for use in your automation, and these accounts are not tied to any specific user. They are what is commonly referred to as a Service Account. In any give IT organization, there can be any number of Service Accounts for quite a wide range of services and technologies. Managing all of those accounts can become quite a burdensome task. There are a number of third party apps that provide tools for managing Service Accounts, but it occurred to me that the concepts are not all that sophisticated and it might be relatively simple to build a Scoped Application to handle the basic management of such accounts.

Here is what I am thinking: A single custom table could be built to store the account details. A second table could be used to store the various types of Service Accounts that could be stored in the main table, and one or more Service Catalog items could be used to manage the accounts. That’s not a huge number of artifacts, so it would appear that you could throw something together rather quickly. You know what I always ask myself: How hard could it be?

So let’s take a look at the lifecycle of an account. To create an account, you would request the account through the Service Catalog, providing all of the necessary information needed to set up the account on the appropriate technology. Let’s assume that the request has to be approved through the normal Service Request approval process, and that the requested item also has to be approved by the technology owner based on the type of account requested. Information on that second level of approval would be stored in the technology type table. Once approved, a fulfillment work flow would initiate, and once again we would turn to the technology type table to determine what specific fulfillment workflow should be executed to fulfill the request. Generally speaking, there would be two types of fulfillment, automated and manual. If the account creating and notification can be handled through automation or integration, then the entire process would be handled without human intervention. If not, one or more tasks would be generated and routed to the appropriate technical support resources. Either way, once the account was created and the requester notified, the requested item would be closed.

Creating the account is only half of account management process. It is never a good idea to just allow these things to live forever once they are created. There needs to be another catalog request process to manually terminate the account, and there should also be some process by which the requester reaffirms the need for the account on some predetermined interval. This Periodic Attestation process could, in fact, be another entirely different stand-alone app that could be used not only for this use case, but quite a number of others. That, however, would be an entirely different collection of blog entries, so we will leave that for another time. Still, we need a way to create an account, alter an account, get rid of account, and every so often, revisit the need for the account to continue to exist.

For our purpose, which is just to demonstrate the concept, we can just have two example technologies, one that we can automate, and one that we cannot (or more accurately, one that we choose to handle with a manual process). That will at least give us a demonstration of how things would work in either use case. Putting this all together, we will need to create the following:

A Scoped Application
A Master account table
A technology type control table
One or more Service Catalog items to create, alter, and terminate accounts
A generic workflow for the catalog item(s)
A type-specific workflow for each type of account in the type table
Some kind of periodic workflow to ensure that the account is still needed.

It’s not a huge list of parts, but there is still a little bit there, so we will just point ourselves in that general direction, start pushing ahead, and see what we run into along the way. Maybe we will use the App Engine Studio for this one and see how far we can get with that. Regardless, it should be a fun little project, so we will jump right into it next time out.

Companion Widgets for SNH Data Tables, Part III

Posted on November 2, 2022 | by snhackery

“Whenever you have taken up work in hand, you must see it to the finish. That is the ultimate secret of success. Never, never, never give up!”
— Dada Vaswani

Last time, we built a companion widget to handle icons and bulk actions. Today we will do something a little different and build a companion widget to handle aggregate columns. Usually, clicking on a aggregate column will bring you to a list of the records represented by the value. If the value was 10, then you would expect to see a list of 10 records, either on a new page or in a modal pop-up. Linking to a new page is already built into the aggregate column specification, so our companion widget example will demonstrate the modal alternative. For our example, we will use catalog requests, with the aggregate column representing the number of requested items in each request.

*A list of requests that includes a count of requested items*

Here is the configuration script used to produce this table:

var MyRequestsConfig = Class.create();
MyRequestsConfig.prototype = Object.extendsObject(ContentSelectorConfig, {
	initialize: function() {
	},

	perspective: [{
		name: 'all',
		label: 'All',
		roles: ''
	}],

	state: [{
		name: 'all',
		label: 'All'
	}],

	table: {
		all: [{
			name: 'sc_request',
			displayName: 'Request',
			all: {
				filter: 'requested_forDYNAMIC90d1921e5f510100a9ad2572f2b477fe^active=true',
				fields: 'number,opened_at,short_description,stage,sys_updated_on',
				svcarray: [],
				aggarray: [{
					name: 'items',
					label: 'Items',
					heading: '',
					table: 'sc_req_item',
					field: 'request',
					filter: '',
					source: '',
					hint: 'Click here to view the items in this request',
					page_id: ''
				}],
				btnarray: [],
				refmap: {
					sys_user: 'user_profile'
				},
				actarray: []
			}
		}]
	},

	type: 'MyRequestsConfig'
});

Without a page_id property in the aggregate column specification, it will not automatically link to another page, but it will broadcast the click event, so we can use a version of the Simple List widget to display our records.

Clicking on an item should bring up the ticket page, where you can see more details about the item.

The reason we need to use a version of the Simple List widget is that the Simple List widget is configured using widget options, and the spModal open() function does not provide the capability of setting the widget’s options. It does, however, provide the capability to configure widget input, so all we need to do is to add these few lines to the top of our version’s Server script to convert that input to options.

// begin mod
	if (input && input.options) {
		for (var name in input.options) {
			options[name] = input.options[name];
		}
	}
// end mod

With that in place, we can now build a typical companion widget that listens for the aggregate click event and pops open our modal dialog using the modified Simple List widget.

api.controller = function($scope, $rootScope, $window, spModal) {
	var c = this;
	var eventNames = {
		referenceClick: 'data_table.referenceClick',
		aggregateClick: 'data_table.aggregateClick',
		buttonClick: 'data_table.buttonClick',
		bulkAction: 'data_table.bulkAction'
	};

	$rootScope.$on(eventNames.aggregateClick, function(e, parms) {
		var modelOptions = {
			title: "${Requested Items}",
			widget: "widget-modal-list",
			widgetInput: {
				options: {
					table: 'sc_req_item',
					filter: 'request=' + parms.record.sys_id,
					display_field: 'number',
					order_by: 'number',
					image_field: 'cat_item.picture',
					secondary_fields: 'stage,cat_item.name',
					sp_page: 'ticket'
				}
			},
			buttons: [
				{label: '${Done}', cancel: true}
			],
			size: 'md'
		};
		spModal.open(modelOptions);
	});
};

And that’s all there is to that. That gives us three different examples covering buttons, icons, bulk actions, and now aggregate columns, so that should cover just about everything. Once you do a few and get the hang of how all of the parts play together, it’s pretty simple to create a new one for a different purpose. For those of you who like to play along at home, here is an Update Set that includes all of the parts and pieces for these various examples. Of course, you will need to install the SNH Data Table Widgets for any of this to be of any value, but you already knew that!

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