“Everything ends; you just have to figure out a way to push to the finish line.” — Jesse Itzler
Last time, we wrapped up the work on the example Service Account dashboard, although we did leave off a few potential enhancements that could improve its value. There is always more that could be done, such as the addition of an Admin Perspective showing all of the accounts and requests or an Expiring State showing all of the accounts that are coming up for review. Since this is just an example, we don’t need to invest the time in building all of those ideas out; some things should be left as an exercise for those who would like to pull this down and play around with it.
What we should do now, though, is take a quick step back and see what we have so far and what might be left to do before we can call this good enough to push out. When we first set out to do this, we identified the following items that would need to be developed:
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.
We have basically created everything on our list except for that last item, but we have also indicated that the process to check back every so often and see if the account was still needed is something that could be handled by a stand-alone generic product that could perform that function for all kinds of things that would benefit from a periodic review. If we assume that we will turn that process over to a third party, then we would seem to have just about everything that we need.
There is one other thing that would be helpful, though, and we neglected to included it on our original list. It would be nice to have some kind of menu item to launch all of these processes that we have built, so let’s put that together real quick and get that out of the way. I am thinking of something like this:
Service Accounts
New Service Account
My Service Accounts
Service Accounts
Service Account Types
The first item would initiate a request for the Service AccountCatalog Item, the second would bring up the dashboard, and the last two would just bring up the list view of our two tables. Those last two would also be limited to admins only and the rest would be open to everyone. Here is the high-level menu entry.
Service Account menu item
… and here are the four submenu options for this high-level menu item:
Service Account menu options
Which produces a menu that looks like this:
New Service Account menu section
So that’s about it for this little example project. Again, this is not intended to be a fully functional product that you would simply install and start using. This is just an example with enough working parts to get things started for anyone who might want to try to create something along these lines. Obviously, you would have your own list of types, your own implementation workflows for each type, your own approval structure for each type, and your own language in all of the notices, so it’s not as if someone could build all of that out in a way that would work for everyone. But for anyone would like a set of parts to play with to get things started, here is an Update Set that contains everything that we have put together during this exercise.
“Beginning in itself has no value; it is an end which makes beginning meaningful; we must end what we begun.” — Amit Kalantri
Last time, we added the Requested Item table to our Service Account dashboard so that we could see the pending requests, but we left off with a field name error and the desire to add a few item variables to the table using some Scripted Value Columns. Today, we will fix up that little error, and add some columns to both tables, hopefully wrapping things up, at least for this version of the dashboard.
In our field list for the new table, we had included the field name opened, when in actuality, the correct field name for the opened date/time is opened_at. That’s an easy fix, and now our field list looks like this:
number,opened_at,request.requested_for,stage
While we are in the configuration updating field lists, let’s also add the new link to the original request to the field list for the Service Account table, which will now look like this:
Also, since that new column will be a link to the sc_req_item table, let’s map that table to the ticket page by adding a new entry to the reference map.
Mapping the Requested Item table to the ticket page
That should take care of the errors and oversights. Now let’s take a look at adding some item variables to the pending request view. We put some catalog item variables on an example table not too long ago, so let’s just follow that same approach and maybe steal a little code from that guy so that we don’t end up reinventing an existing wheel. Here is the script that we built for that exercise.
var ScriptedCatalogValueProvider = Class.create();
ScriptedCatalogValueProvider.prototype = {
initialize: function() {
},
questionMap: {
cpu: 'e46305fbc0a8010a01f7d51642fd6737',
memory: 'e463064ac0a8010a01f7d516207cd5ab',
drive: 'e4630669c0a8010a01f7d51690673603',
os: 'e4630688c0a8010a01f7d516f68c1504'
},
getScriptedValue: function(item, config) {
var response = '';
var column = config.name;
if (this.questionMap[column]) {
response = this.getVariableValue(this.questionMap[column], item.sys_id);
}
return response;
},
getVariableValue: function(questionId, itemId) {
var response = '';
var mtomGR = new GlideRecord('sc_item_option_mtom');
mtomGR.addQuery('request_item', itemId);
mtomGR.addQuery('sc_item_option.item_option_new', questionId);
mtomGR.query();
if (mtomGR.next()) {
var value = mtomGR.getDisplayValue('sc_item_option.value');
if (value) {
response = this.getDisplayValue(questionId, value);
}
}
return response;
},
getDisplayValue: function(questionId, value) {
var response = '';
var choiceGR = new GlideRecord('question_choice');
choiceGR.addQuery('question', questionId);
choiceGR.addQuery('value', value);
choiceGR.query();
if (choiceGR.next()) {
response = choiceGR.getDisplayValue('text');
}
return response;
},
type: 'ScriptedCatalogValueProvider'
};
We can make a copy of this script and call ours ServiceAccountDashboardValueProvider. Most of this appears to be salvageable, but we will want to build our own questionMap using the columns that we will want to use for our use case. To find the sys_ids for the variables that we will want to use, we can pull up the Catalog Item to get to the list of variables, and then pull up each variable and use the context menu to snag the sys_id for each one.
Grabbing the sys_id for each desired catalog item variable
Once we gather up all of the sys_ids, we will have a new map that looks like this:
That should be enough to make things work; however, in our case the types of variables involved will return the display value directly, so we do not need to go through that secondary process to look up the display value from the value. We can simply delete that unneeded function and return the value directly in this instance. That will make our new script look like this:
var ServiceAccountDashboardValueProvider = Class.create();
ServiceAccountDashboardValueProvider.prototype = {
initialize: function() {
},
questionMap: {
account_id: '59fe77a4971311100362bfb6f053afcc',
type: 'f98b24a4971711100362bfb6f053afa0',
group: '3d4fbba4971311100362bfb6f053afe3'
},
getScriptedValue: function(item, config) {
var response = '';
var column = config.name;
if (this.questionMap[column]) {
response = this.getVariableValue(this.questionMap[column], item.sys_id);
}
return response;
},
getVariableValue: function(questionId, itemId) {
var response = '';
var mtomGR = new GlideRecord('sc_item_option_mtom');
mtomGR.addQuery('request_item', itemId);
mtomGR.addQuery('sc_item_option.item_option_new', questionId);
mtomGR.query();
if (mtomGR.next()) {
response = mtomGR.getDisplayValue('sc_item_option.value');
}
return response;
},
type: 'ServiceAccountDashboardValueProvider'
};
Now all we need to do is to pull up the dashboard under the new configuration and see how it all looks. First, let’s take a look at the new column that we added for the original request.
Modified dashboard with new Original Request column
There is only data there for the most recent test, but that’s just because that field did not exist on the table until recently. Now let’s click on the Pending state and see how our item variables came out.
Pending requests with item variable columns
Very nice! OK, I think that about does it for this version of the sample dashboard. There is still some work that we could do on the Fulfiller perspective, and it might be nice to add an Admin perspective that showed everything, but since this is just an example of what might be done, I will leave that as an exercise for those who might want to play around with things a bit. Next time, let’s take a look at what now have up to this point, and at what there might be left to do before we can wrap this one up and call it done.
“There is joy in work. There is no happiness except in the realization that we have accomplished something.” — Henry Ford
Last time, we fixed a few problems with our ServiceNow account password, which wrapped up the work on that particular Subflow. That was also enough to prove out our primary Flow for fulfilling the Catalog Item we built to request a new Service Account. Now it is time build another Subflow for our other example account type, Active Directory. This time, instead of an automated fulfillment process (which, of course, is possible for A/D with some integration) we are going to assume that some technician has to create the account, so we will be issuing a Catalog Task to the folks who would be doing that. This is just to demonstrate the manual fulfillment process as opposed to the automated approach that we used last time.
Before we do that, though, let’s take a quick side trip to add Stages to our primary Flow. Flows associated with Catalog Items should always identify the fulfillment stages to provide insight into the status of the fulfillment process. We can add Stages to the Flow in the App Engine Studio by pulling up the Flow, clicking on the More Actions menu (‘…’) in the upper right-hand corner, and selecting Flow stages from the drop-down menu. Select Requested Item from the Add stages from a template selection and then click on the Add stages button. This will pull in all of the Stages defined for a Requested Item. Now all we have to do is to click on the Add a Stage button in the space above each step that begins a new Stage and choose the appropriate stage from the available list.
Adding Stages to the Flow
I selected Fulfillment for the initial Stage, Delivery for the step that creates the record in our account table, and Completed when the password email is sent out. Also, not shown on that screen shot, I selected Request Cancelled when the Service Account could not be created. That should be enough to get us started, but we may find the need to fine tune that a little bit once we see how it all comes out in testing.
There is one other thing that we need to do before we jump into building out the manual Subflow for Active Directory accounts. Since we are assuming that a technician will be creating the account and setting the initial password, we will need some way for the technician to provide the password back to the primary Flow so that it can be communicated to the requestor via the notification email. One way to do that would be to add one more variable to our Catalog Item and hide it everywhere except on the task record. Once the task is closed, we can then lift the value off of the task, pass it back to the primary Flow and then clear the value on the task record, as it will no longer be needed. With that out of the way, we should now be able to build out our new Subflow.
To begin, let’s pull up our old friend the Flow Designer and create a new Subflow called Active Directory Service Account Creation. We will use the same inputs and outputs that we created for our ServiceNowSubflow, as that is what our calling Action requires.
Subflow inputs and outputs
The first thing that we will want to do is to create the task, and there is an action already set up to do just that, so we select that and populate all of the appropriate fields.
Catalog Task creation step
We also want to check the Wait box, as we do not want the rest of the Flow to run until the task has been completed and we can see how it turns out. And we want to snag the variables that we need from the request so that they will be available on the task record.
Catalog Task creation step (continued)
Once the task is no longer active, we will want to check to make sure that it was completed successfully. We can do that with an If condition that looks to make sure that the State of the ticket is Closed Complete. If it is, then we will want to grab the password entered by the technician so that we can pass it back to the calling Flow. To do that, we use the Get Catalog Variables action.
Grabbing the password from the task record
Once we have a data pill with the password value that we can use for our Subflow outputs, we do not need to have the value in the database. We will want to clear the value from the new password variable that we just added. Unfortunately, while there is an existing Get Catalog Variables action shipped with the platform, there is no corresponding Set Catalog Variables action that we can use to remove the value of the variable. For that, we are going to have to create yet another custom Action.
Even though an Action that clears the value of a variable is relatively simple, creating a custom Action is a little bit of an involved process. This seems like a good place to stop for now, then, and we can jump right into creating that new Action right at the top of our next installment.
“Mistakes are part of the dues one pays for a full life.” — Sophia Loren
Last time, we did a little testing on our new Catalog Item fulfillment Flow and discovered that the password was not set up correctly on the requested ServiceNowService Account that was created during the process. Before we get too worked up about that problem, though, we should at least celebrate the fact that the primary Flow worked as intended, calling the type-specific Subflow to create the account, and then notifying the requester and closing out the Requested Item. Also, the Subflow that we set up for ServiceNow accounts also worked for the most part, creating the account and sending the details back to the main Flow. Of course, none of that really matters if you cannot successfully sign on using the password sent to the requester. So we do have to deal with that today, but other than that, things are actually looking pretty good.
So, what to do about the password issue? Well, like many things on the Now Platform, there are a variety of ways to go here. Using script, we can set the clear text password by using the setDisplayValue method instead of the setValue method. To do that, though, we would have to create the account first, and then add some kind of additional step where we could dip into scripting, most likely some kind of custom action. If we have to add another step, though, there is already an Update Password action that we can use, but rather than a String input, it requires that you pass in a 2-way encrypted value. Although that adds its own unique complexities to the process, it is actually a better way to go, as it keeps the clear text password value out of the execution log where malicious actors might stumble upon it. So let’s go that route, as it not only addresses this issue, but improves the process overall.
The first thing that we need to do then is to change the variable type for every occasion of the account_password variable from String to Password (2 Way Encrypted). This affects the primary Flow, all type-specific Subflows, as well as the Action that we created to generate the password. Initially, I thought that the password field would have to be encrypted before delivering it to the Action outputs, but it turns out that this is all handled internally once you change the field type, and all you have to do is to return the clear text password just as we were doing originally.
Now that we are generating and passing around an encrypted password, we can remove the password field from the original account creation step in the Subflow and then add a new step right after the account has been created to set the password.
Adding an Update Password step
That takes care of the password issue, but there is still one more thing that we may need to do. Since we switched from passing around the clear text password to using the encrypted password, we might have to decrypt it before we send it out to the requester. For now, let’s just drag in the account_password pill from the account creation step and see what happens. If that doesn’t work out for us, we will have to do a little more research and see what we have to do to get the encrypted password back into clear text for the email step.
That completes all of the modifications so now all that is left is to place another order and see if all of the stuff that worked last time is still working and if we are now sending the requester a password that they can actually use. We’ll go through the same steps that we went through last time, so no need to repeat all of that here, but let’s take a look and see how things turned out when we repeated all of those ordering steps.
… and now we have a new problem!
Well, there is good news and bad news here. The good news is that the switch to Password (2 Way Encrypted) has indeed corrected the issue with the password. The password that would have been sent to the requester is, in fact, the password that you can use to log on to ServiceNow with the new account. The bad news is that the special characters in the password caused a problem with the HTML in the password email. The simple solution to that would be to change the email body format from HTML to plain text, but I don’t see any way to do that with the options available on the Send Email action.
I took a look at all of the data pill transform options, but there doesn’t seem to be a built-in function to sanitize a string for HTML, so I ended up wrapping the password data pill with a <pre> tag and that seems to have resolved the issue.
There are still a few things that we could do to improve things a bit, but everything seems to be working at this point. We still have to build out another Subflow for our second account type example, though, so let’s jump right into that next time out.
“Success is stumbling from failure to failure with no loss of enthusiasm.” — Winston Churchill
Last time, we wrapped up our Catalog Item by specifying the Flow that we created as the fulfillment method. Now we just need to test everything to make sure that it all works. The easiest way to do that is to jump into the Service Catalog and place an order. Let’s do that now.
Service Account Catalog Item in the Service Catalog
To request a new Service Account, we just need to complete all of the required fields that we created for this item.
Completing the request for a new Service Account
Since the only fulfillment Subflow that we have created so far is for a ServiceNowService Account, we will select that from the list and then complete the rest of the form. Clicking on the Request button creates the request and takes you to the summary page for the newly created request.
Newly created Service Request
Clicking on the name of the Requested Item brings you to the summary page for that item, that shows that it has, in fact, been fulfilled.
Fulfilled Requested Item
The status of the Requested Item is Closed Complete, and it includes the comment: Service Account testacct1 has been created and the requester has been notified. To verify the notification, we can jump over to the email logs and see if we can find an outgoing email for this request.
Outgoing notification email
One other thing that we will want to check is whether or not the account was actually created, so let’s pop over to the user list and see if we can find the user record.
Requested ServiceNow Service Account
So far, so good. Now let’s see if we can use the account. You shouldn’t be able to log on to ServiceNow with this account, but let’s try that anyway and see what happens.
Invalid log on attempt
Although the image above was what I was expecting to see, the only way I got that was to reset the password on the new Service Account. When I first attempted to log in directly, I got an invalid password message. What that tells us is that the method that I used to set the password when we first created the record did not work. Apparently, you cannot just set the password field to a specific value; there must be some other, more secure way to do that aside from just passing in the value. I’ll have to do a little research on the appropriate way to go about that, make a few changes, and then test again. It’s always something! Well, now we have the subject matter for our next installment.
“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.
Select Flow from the available options
On this screen, we simply select Flow from the available options, which takes us to the next screen.
Flow definition
On this screen we enter Service Account Request Fulfillment in both the Name and the Description fields and then click on the Continue button.
Flow creation
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.
Flow creation completion
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.
Checking the Subflow success
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.
Fetching the user group record
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.
Closing the Requested Item
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.
Sending the password to the requester
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.
“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.
Inputs and Outputs of our new Subflow
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 AccountCatalog 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.
Generating a new password
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.
“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.
Catalog Item 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.
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.
Catalog and Category selections
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.
Catalog Item Questions 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.
Service Account Type question
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.
Full list of Catalog Item Questions
Once we have completed all of the Questions for our item, the next step is to move on to the Settings section.
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.
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.
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.
“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.
Table edit tab
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 the Reference field type
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.
Completed Service Account table
Now we need to do the same thing for our technology type table, which will have even fewer fields.
Service Account Type table
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 ServiceNowService 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.
Adding data to a 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.
Service Account Type 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.
Example Service Account Types
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.
New Catalog Item data entry form
Once you enter all of the requested data and click on the Continue button, the new Catalog Item is created.
Catalog Item creation
After you sit and watch that screen for a bit, you are eventually taken to the completion screen.
Catalog Item completion
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.
