Reference field – snhackery

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.

sn-record-picker Helper, Part II

Posted on March 16, 2020 | by snhackery

“If I had eight hours to chop down a tree, I’d spend six hours sharpening my ax.”
— Abraham Lincoln

Now that we have all of the form fields and controls laid out on the page, the next order of business is to build the function that will use the form input to create the desired sn-record-picker. We have already specified an ng-submit function on the form, so all we have to do at this point is to actually create that function in the client-side script. This function is actually pretty vanilla stuff, and just takes the data entered on the screen and stitches it all together to form the resulting sn-record-picker tag.

$scope.createPicker = function() {
	var picker = '<sn-record-picker\n    table="' + "'";
	picker += c.data.table.value + "'";
	picker += '"\n    field="';
	picker += c.data.field;
	if (c.data.filter) {
		picker += '"\n    default-query="' + "'";
		picker += c.data.filter + "'";
	}
	picker += '"\n    display-field="' + "'";
	picker += c.data.displayField.value + "'";
	if (c.data.displayFields.value) {
		picker += '"\n    display-fields="' + "'";
		picker += c.data.displayFields.value + "'";
	}
	if (c.data.searchFields.value) {
		picker += '"\n    search-fields="' + "'";
		picker += c.data.searchFields.value + "'";
	}
	if (c.data.valueField.value) {
		picker += '"\n    value-field="' + "'";
		picker += c.data.valueField.value + "'";
	}
	if (c.data.multiple) {
		picker += '"\n    multiple="true"';
	}
	if (c.data.placeholder) {
		picker += '"\n    page-size="';
		picker += c.data.pageSize;
	}
	if (c.data.pageSize) {
		picker += '"\n    placeholder="';
		picker += c.data.placeholder;
	}
	c.data.generated = picker + '">\n</sn-record-picker>';
	c.data.ready = true;
	return false;
};

One of the last few things that happens in that script is to set c.data.ready to true. I set that variable up to control whether or not the rendered tag should appear on the screen. Altering any of the fields on the screen sets it to false, which hides the text box containing the generated code until you click on the button again. To make that work, I just added an ng-show to the enclosing DIV:

<div class="col-sm-12" ng-show="c.data.ready">
  <snh-form-field
    snh-model="c.data.generated"
    snh-name="generated"
    snh-label="Your sn-record-picker:"
    snh-type="textarea">
  </snh-form-field>
  <p><a href="javascript:void(0);" onclick="copyToClipboard();">Copy to clipboard</a></p>
</div>

The other thing that you will notice inside of that DIV is the Copy to clipboard link. That one uses a standard onclick rather than an ng-click, because that’s a DOM operation, which is outside the scope of the AngularJS controller. The referenced script, along with another DOM script that I use to set the height of that textarea, are placed in a script tag with the HTML.

<script>
function fixTextareaHeight() {
	var elem = document.getElementById('generated');
    elem.style.height = (elem.scrollHeight + 10)  + 'px';
}
function copyToClipboard() {
	var elem = document.getElementById('generated');
	elem.select();
	elem.setSelectionRange(0, 99999)
	document.execCommand('copy');
	alert("The following code was copied to the clipboard:\n\n" + elem.value);
}
</script>

Clicking on that Copy to clipboard link copies the code to the clipboard and also throws up an alert message to let you know what was copied.

*Alert message after copying the code to the clipboard*

The next thing on my list was to actually place the code on the page so that you could see it working. I tried a number of things to get that to work, including ng-bind, ng-bind-html, ng-bind-html-compile, and sc-bind-html-compile, but I could never get any of that to work, so I ultimately gave up on trying to use the actual generated code, and did the next best thing, which was to just set up a picker of my own using the selected options.

        <div class="col-sm-12" ng-show="c.data.ready">
          <snh-form-field
            snh-model="c.data.liveExample"
            snh-name="liveExample"
            snh-label="Live Example"
            snh-type="reference"
            snh-change="optionSelected()"
            placeholder="{{c.data.placeholder}}"
            table="c.data.table.value"
            display-field="c.data.displayField.value"
            display-fields="c.data.displayFields.value"
            value-field="c.data.valueField.value"
            search-fields="c.data.searchFields.value"
            default-query="c.data.filter">
          </snh-form-field>
        </div>

This approach allowed me to add a modal pop-up that showed the value of the item selected.

*Modal pop-up indicating option selected*

The code to make that happen is in the client-side controller:

$scope.optionSelected = function() {
	spModal.open({
		title: 'Selected Option',
		message: '<p>You selected  "<b>' + c.data.liveExample.value + '</b>"</p>',
		buttons: [
			{label: 'Close', primary: true}
		],
		size: 'sm'
	});
};

One other thing that I should mention is that the snh-form-field directive that I used in this example is not same as the last version that I had published. To support the multiple=true/false option, I needed a checkbox, and for some reason, I never included that in the list of many, many field types that included in that directive. I also had to tweak a few other things here and there, so it’s no longer the same. I should really release that separately in a future installment, but for now, I will just bundle it with everything else so that this will all work as intended.

I wrapped the whole thing in an snh-panel, just to provide the means to add some documentation on the sn-record-picker tag. I had visions of gathering up all of the documentation that I could find and assembling it all into a comprehensive help screen document, but that never happened. Still, the possibility is there with the integrated help infrastructure.

I also added a sidebar menu item so that I could easily get to it within the main UI. It may be a Service Portal Widget under the hood, but it doesn’t really belong on the Service Portal. It’s a development tool, so I added the menu item so that it could live with all of the other development tools in the primary UI. If you want to take it for a spin yourself, here is an Update Set.

Update: There is a better (corrected) version here.

Reference Type System Properties

Posted on January 2, 2019 | by snhackery

“To succeed in life, you need two things: ignorance and confidence.”
— Mark Twain

Whenever I create a ServiceNow application, I invariably end up setting up one or more System Properties to control the behavior of the app, set up options for the app, or allow the app to function differently in different environments such as Test or Production. Recently, I wanted to create a property that would be selected from a table, or in ServiceNow terms, a Reference property. Unfortunately, when I scanned the list of available property types, Reference was not on the list.

Well, not to worry. Choice Lists are easily modified, so I went to sys_properties.list, then Configure -> Table, and clicked on the Type column to bring up the Dictionary Entry. From there, I clicked on the Choices (13) tab and then clicked on the New button to create a new choice. I typed the word reference into both the Label and Value fields and then clicked on the Submit button to save the new choice. Voila! Now my instance supports System Properties of Type Reference:

New Reference Type added to the Choice List

Of course, that was the easy part … there’s still much to do. First of all, we are going to need to add another field so that we can capture the Table we will be using for the Reference. And now that I am looking at that form, there are a couple of things that are irritating my sense of The Way Things Ought To Be that I am just going to have to clean up while I’m in there. For one, the need for the Choices field is dependent on the value of the Type field, so the Type field should come first. Additionally, the Choices field shouldn’t even appear on the form if the Type is not Choice List. The new Table field, which itself should be a Reference to the Table table, should only appear if the Type is Reference. If the Type is not Choice List and the Type is not Reference, then the very next field should be Value. Let’s see if we can’t clean all of that up next.

To begin, we can add the new column to the sys_properties table right from the form itself using the hamburger menu:

This will take us to the list of columns where we can click on the New button to create a new column on the table. Select Reference as the Type, enter Table as the Label and then go down to the Reference Specification tab and select Table as the Reference.

Saving the new column will return us to the Table specification, and clicking on the return (<) icon up in the left corner will get us back to the form where we can use the hamburger menu to select Configure -> Form Layout to move things around. Doesn’t that look better!

Now, with a little UI Policy magic, we can hide both the original Choices and the new Table unless the appropriate Type has been selected. Back again to the hamburger menu where we can select Configure -> UI Policies to implement the desired changes. We’ll need to add two new policies, one for the Choices field and one for the Table field. You first have to create the policies and save them, then you can go back in and add the actions to take when the conditions are met. The condition on the first will be Type = choice list and the condition on the second will be Type = reference. Be sure the check the Reverse if false option, as we will want these policies to toggle between the true and false conditions.

Once the policies have been created, you can go back in and add the appropriate action. On the Type = choice list policy, the action will be to make the field Choices visible. On the Type = reference policy, the action will be to make the new field Table visible. Because you selected the Reverse if false option on both policies, when the the Type is not set to the specified value, the result will be that the relevant field will no longer be present on the screen.

System Property form with neither Choice List nor Reference selected

There are still a couple of more things that we could do here to make this complete, but at this point I don’t really have a pressing need for either, so I am just going to let those go for now. The first would be a potential filter for the reference fields, as there are occasions where you don’t want the user choosing from the entire contents of the table. That would basically be handled like the Table field itself, appearing on the form only when reference was selected as the Type.

The other thing that could be done at this point would be to alter the Value field to behave in accordance with the selected Type. This would seen like the appropriate thing to do, but out of the box, the open text input box does not transition to a selection of choices when you select choice list as the Type. I think the main reason that it doesn’t do that is because this is not really the place where property values are set. Properties are defined on this form, but there is another form that is generally used to set the value. We’ll tackle that form next time, as that work will be a job in and of itself.

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