Service Account – Page 2

Service Account Management, Part XVI

Posted on February 14, 2023 | by snhackery | 2 Comments

“Inside of every problem lies an opportunity.”
— Robert Kiposaki

Last time, we wrapped up all of the work on the Service Account requisition process, although we left a number of things that could have improved the process to some mythical future effort. Unlike the SNH Form Fields or SNH Data Table Widgets, which were intended to be used as is, without the need to touch any of the provided code, the Service Account Management app is more of a sample of what could be done, with the understanding that implementers would want to craft their own account types, notice templates, and fulfillment Flows based on their unique requirements. Since it is just an example, and more of a concept than a product, we don’t need to solve every issue or build out every conceived improvement. We created enough pieces to demonstrate that it works, and that pretty much addresses the intent of the project.

So what’s left? One thing that we will want to do once a Service Account has been delivered will be to check back every so often and ensure that it is still needed. This is actually a common practice for a number IT artifacts, and the applications for such a process go well beyond the realm of Service Accounts. Periodically checking to see if a thing is still needed is something that could be applied to servers deployed for a development project, or access granted to vendors or contractors, or laptops issued to temporary staff, or communications links established with outside entities, or any number of other items that are deployed, granted, or procured for a limited purpose. That actually could be a stand-alone product that one could use out of the box, and one that could potentially have quite a few applications in an IT organization. In fact, for our little exercise here, let us assume that such a product exists, and we won’t bother to build out that capability here. However, one day we might tackle the development of such a product, and if we do, we can then use our Service Account Management app as one example of how such a product might be employed. But that’s not today’s worry.

So, again, what is left for us to do. So far, we have created our Scoped Application, built out all of our database tables, and created a process through which someone can request a new Service Account. If we assume that the periodic process though which these accounts will be reviewed will be handled by a separate product, then what is left for our product?

One thing that would be useful would be series of table views from both the requester’s perspective and the fulfiller’s perspective. Each might want to see a list of active accounts, retired accounts, and pending accounts. This is something for which the SNH Data Table Widgets were designed, so let’s see if we can use that product to produce a single dashboard that would contain all of these interrelated lists.

To begin, we will select Content Selector Configurator from the Tools menu (which is only there because we have previously installed SNH Data Table Widgets).

*Selecting the Content Selector Configurator from the Tools menu*

On the initial screen of the configurator, we will want to click on the Create a new Content Selector Configurator button.

*Creating a new Content Selector Configurator*

We will call our new script ServiceAccountDashboardConfig and use the Add a new Perspective button to create two perspectives, Requester and Fulfiller. We may want to add a third at some point for an Admin view, but for now, let’s just focus on the two primary user perspectives. Once we click on the Add a new Perspective button, a modal dialog pops up where we can enter the details of our new perspective.

*Incomplete modal pop up for adding a new perspective*

Well, that’s not right! The modal pop-up box is supposed to have several input fields and it is only tall enough to show the first one. There doesn’t seem to be any way to drag down the bottom of the box to reveal the rest of the form, either, so you can’t even get to the buttons that should be down at the bottom. This is probably another Tokyo thing that I am going to have to resolve, so it looks like it is time to set this project aside and dig into this little issue.

It’s always something.

OK, well, I will see if I can’t figure out what is going on here, and once I do, we will get back to this in a future installment. Hopefully, this will be a quick break!

Service Account Management, Part XV

Posted on February 1, 2023 | by snhackery

“It’s a bad plan that admits of no modification.”
— Publilius Syrus

Last time, we wrapped up changes to our primary new Service Account request fulfillment Flow, and our second example Subflow for manually creating a new Active Directory account. Now we need to test everything all over again to make sure that we didn’t break anything, and to see if we finally have a working approach to the manual fulfillment process. Once again, let’s start with the automated example first, as that is the one that was working previous to all of these changes.

*Testing the automated fulfillment process once again*

… and it looks like that one still works, even with all of the alterations that we just did.

*Successful account creation and task closure*

Now let’s try the same thing with the manual fulfillment example.

*Testing the manual fulfillment process*

Under this scenario, the Requested Item will remain open until someone closes the task issued to the fulfillment group.

*Requested Item waiting for manual fulfillment*

So let’s hunt down the task, pretend that we created the account manually, and then close it and see what happens.

Now the Requested Item shows completed, which also closes out the Request.

So now both the automated and manual example Subflows appear to do what they are supposed to do, which should complete the work on the Service Account creation process. Before we go, however, we should check the password emails sent out for both, just to make sure that those are working as they should as well. Here is the email sent out for the automated example.

*Password email for the automated example test*

And here is the email for the manual example.

*Password email for the manual example test*

Both look good, so it would appear that we have a successful strategy for fulfilling the requests for new Service Accounts of any type. To create a new type, you would just need to add the new record for the type to the table and then specify the appropriate Subflow on the new type record. This would make the new type appear on the catalog item drop-down list and the primary fulfillment Flow would then launch the Subflow specified in the type record during fulfillment.

As mentioned earlier, there is some work that we could do to streamline this process with a little bit of refactoring, but since it does work, we will leave that for another day at this point and move on to other things. In fact, those other things will be the subject of our next installment.

Service Account Management, Part XIV

Posted on January 30, 2023 | by snhackery

“Take chances, make mistakes. That’s how you grow.”
— Mary Tyler Moore

Last time, we modified and tested the automated example Subflow using our new approach, so now we have to do the same thing with our manual example. Because we are now creating our Catalog Task in the primary Flow, much of the work that was previously done in the earlier version of the Subflow has now been moved to the primary Flow, so there won’t be much left to do in the manual version of the Subflow. In fact, it may even be possible to create a generic Subflow that would handle all manual implementations. For now, though, let’s just create one specifically for our example and we can explore that possibility at some later point.

Under our new approach with two parallel tracks (one for the task creation and the other for launching the type-specific Subflow), we cannot put any post-task-closure logic in our Subflow since the wait logic is in one track and the Subflow is running independently in another. In our original example, once the task closed we pulled the password out of a catalog variable and then removed that value from the variable so it would not be left on the records after processing. We still need to do this, but since it cannot be done in the Subflow, we will have to move these steps to the primary Flow. And since the password was originally sent back in the Subflow outputs, which will continue for all automated implementations, we need to set up a Flow Variable that can be populated from either track to make all of this work for both types.

To create a Flow Variable in the App Engine Studio, pull up the primary Flow and use the ellipses menu in the upper right-hand corner to select Flow Variables.

We will call our new variable password and set the type to String. It would be nice to set the type to Password or some other masked data type, but in the current version, that does not appear to be an option.

Now that we have our variable defined, we can populate it in both parallel branches where appropriate, and then use in the outgoing email instead of using the Subflow outputs. Under the branch that creates the Catalog Task, we can add a new step to pull the password value out of the variables linked to the task.

*Pulling the password value out of the Catalog Task variables after task closure*

Now, the one thing that we do not want to do is to overlay a value provided by the other branch running the Subflow, so before we use this value to populate our new variable, we will want to make sure that a value is there. To do that, we add a simple If condition.

*Checking for the presence of a password value*

Once we know that a password was provided, indicating a manually fulfilled request, we then use that value to populate our Flow Variable.

*Setting the value of the Flow Variable*

That should take care of the first parallel branch. Now we need to do something similar for the second branch. After we run our Subflow, we can pull the password value returned by the Subflow and use it to populate our new variable.

*Populating the variable from the Subflow outputs*

Now we just need to go into the step that sends out the email containing the password and change the source of the email body from the Subflow outputs to the new variable.

*Sending out the password from the variable instead of the Subflow outputs*

That should take care of all of changes for the primary Flow. In fact, virtually all of the work that was done in the original manual example Subflow has now been moved to the primary Flow, so there isn’t much left to do in the Subflow. Let’s pull that guy up now and strip out everything that we are now handling in the Flow and see what’s left.

*Stripped down version of the manual fulfillment Subflow*

As you can see, the only thing left in the Subflow is to assign the Subflow outputs. This would indicate that we could do yet another redesign and have either a generic manual Subflow, or make the Subflow optional and only include one if the fulfillment is automated. We could add the owner instructions to the type record, fetch both the password and the success/failure from the task, and then even the automated Subflows would have no need for outputs. They would communicate to the primary Flow via the task record. But before we get too far ahead of ourselves, let’s see if all of this works as it is. Now that we have modified the primary Flow, we will need to retest both the automated example and the manual example to see if they both work. That sounds like a good subject for our next installment.

Service Account Management, Part XIII

Posted on January 25, 2023 | by snhackery

“Challenges are what makes life interesting and overcoming them is what makes life meaningful.”
— Joshua J. Marine

Last time, we finished up with the modifications to our primary fulfillment Flow, so now we need to modify one of our example Subflows so that we can test out this new approach to the design. Since we already had the first example working under the old design, let’s start with that one, the one that builds ServiceNow Service Accounts. Even though we did not build the Subflows in the App Engine Studio, they do appear there once they are created, so we can edit them while in the studio without having to resort to the older Flow Designer.

*Selecting the Subflow from the dashboard*

The first thing that we will want to do is to alter the input from a Requested Item to a Catalog Task.

Next, we will need to alter the source of the Requested Item record in the first step. Now that we are using the Catalog Task as input, we will have to pull the Requested Item record from the appropriate Catalog Task property.

*Getting the Requested Item record from the Catalog Task*

The remainder of the existing workflow should be OK as it is, but under our new approach, our automated Subflow has one additional responsibility: we need to close the Catalog Task, both for a successful completion and for any kind of failure. Let’s handle the success story first by inserting an Update Record action just before we assign the Subflow outputs.

*Closing the task on a successful completion*

On the failure branch, we need to do the same thing, with different values, right before we assign the Subflow outputs at the end of that process.

At this point, all we need to do is to Save and Activate the Subflow and take it out for a spin. The easiest way to try it out would be to jump into the Service Catalog and place another order.

Looking at the resulting Requested Item reveals that the Flow and Subflow executed successfully and the account was created.

*Resulting Requested Item in Closed Complete state*

So the Subflow that was working before is now working again using our new approach. Now we have to modify the manual example that wasn’t working before and see if that guy works under our new approach as well. Let’s jump into that next time out.

Service Account Management, Part XII

Posted on January 13, 2023 | by snhackery

“Never put off until tomorrow what you can do the day after tomorrow.”
— Mark Twain

Last time, we started reworking our primary fulfillment Flow to resolve the problem that we encountered during the testing of our second example Subflow. In the midst of that process, we found that we needed to rework the inputs on our custom Action that calls the type-specific Subflow, so let’s fire up our old friend the Flow Designer and take care of that now. The first thing that we will want to do is to delete the existing Requested Item record input.

*Deleting the existing input for the Requested Item*

Once that is gone, we will want to replace it with a new input for the Catalog Task.

Next, we need to jump down to the script step and modify its inputs in the same way and map the new catalog task input to the matching action input.

*Mapping the new Catalog Task input to the script step’s inputs*

And finally, we will want to modify the script to pass in the new catalog_task variable instead of the original requested_item variable.

(function execute(inputs, outputs) {
	try {
		var result = sn_fd.FlowAPI.getRunner()
			.subflow(inputs.subflow)
			.inForeground()
			.withInputs({catalog_task: inputs.catalog_task})
			.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);

Now we can Save and Publish our modified Action and get back to our work on the primary Flow, but before we can test anything, we will need to modify all of our Subflows. For one thing, our Subflows are not expecting to receive a Catalog Task right now, and of course, since we are sending in a Catalog Task, that will requiring altering the logic in both of our example Subflows. But let’s finish up the primary Flow before we worry too much about that.

Now that our Create Service Account custom Action takes a Catalog Task as an input, we can drag the data pill from the Look Up Record step into the appropriate input and click on the Done button.

*Mapping the Catalog Task to the action input*

At this point, the rest of the primary Flow should continue to work as originally conceived. Future steps will not execute until both parallel branches have been completed, so automated Subflows should end when the second branch is completed and manual Subflows should end when the first branch is completed. Either way, the rest of the primary Flow should execute as before once both branches have finished their work.

The next thing that we will need to do before we can resume testing is to modify one or both of the example Subflows. Both of those will require a bit of redesign to accommodate our new approach, so that sounds like a great subject for our next installment.

Service Account Management, Part XI

Posted on January 10, 2023 | by snhackery

“Don’t waste your time being upset about something you can’t change. Begin again and do it better this time.”
— Joyce Meyer

Last time, we finished up our second fulfillment Subflow and took it out for a spin. Unfortunately, our first test of the new process died before it ever really got off of the ground. It turns out that you cannot launch a Subflow from a script when that Subflow contains a manual task that may not be completed for some time. Our Subflow ended with an error message indicating that the Subflow was in a wait state, which is actually true, as the Subflow was waiting for the manual task to be completed.

*Failed text of second fulfillment Subflow*

This is no small problem. If we cannot convince the script to wait for the manual task to be completed, then we are going to have to rethink the entire approach to the primary Flow. We don’t really need a task to be created when the process is automated, but we could still open up the task in the primary Flow, and then pass the task to the Subflow instead of the Requested Item. This would mean that any automated Subflows would have the responsibility of closing the task, but that would work. The problem, of course, is that if you check the Wait box on the task, no further steps in the process will execute until the task is closed, and the task isn’t set to be closed until you execute those future steps. That’s not going to work!

Fortunately, the Flow Designer allows you to run separate steps in parallel. We can create the task in one branch and then call the Subflow in a separate parallel branch. This should work, although it is a complete redesign of everything that we have put together so far in the fulfillment realm. Oh, well … as one of my previous supervisors used to tell me all the time, if it was easy, then anyone could do it!

So here is what we need to do: instead of calling the appropriate Subflow and passing in the Requested Item, we will need to create two parallel paths with one responsible for creating the task and waiting for its completion and the other responsible for calling the appropriate Subflow. Since you cannot drag data pills from one parallel branch to another, our second branch will need to wait for a bit to insure that the task has been created, and then read the task from the database so that it can have a task data pill to pass in to the selected Subflow. This changes quite a number of artifacts that we have already built, so let’s dive in and start hacking things up. To begin, let’s pull up our primary Flow in the App Engine Studio and insert a Do the following in parallel Flow Logic step right after we fetch the Service Account Type record.

Under the first parallel path we will create our task using the Create Catalog Task action.

We will assign the task to the fulfillment group specified in the type record so that the task gets routed to the appropriate fulfillment group. For automated fulfillment processes, the automation will need to close the task with the appropriate closure code before returning to the primary Flow, which should keep the task from showing up in that group’s active work queue.

Our other branch will need access to that task record, but since you cannot drag data pills from one parallel branch to another, we will need to fetch the record from the database. Before we do that, though, we will want to make sure that the other branch has created the record, so we will want to wait a bit before we go searching for it. We can do that with another Flow Logic option, Wait for a specific duration of time.

*Waiting for the task record to be created*

10 seconds may be way too much time, or it may not be enough in some circumstances, but it is a good place to start and we can adjust it in the future if needed. After waiting for the record to be created, the next thing that we will want to do is to fetch the record so that we can pass it in to our appropriate Subflow. To do that, we will use a Look up record action.

Now that we have our task record in hand, we can drag our existing Create Service Account action in under this second parallel branch as the next step. However, the current version of the action is expecting a Requested Item record as input, and under this new approach, we are going to want to pass in the Catalog Task instead. We will need to modify that action to alter the input, which will also affect all of our existing Subflows as well. That sounds like a good subject for our next installment.

Service Account Management, Part X

Posted on January 3, 2023 | by snhackery

“The only difference between a problem and a solution is that people understand the solution.”
— Charles Kettering

Last time, we started building out the second of our example fulfillment Subflows when we determined that we needed to build a custom Action to clear out the password value from the new Catalog Item Variable that we created so that the fulfilling technician could provide the new account’s password to the Flow. This is a relatively simple Action, so let’s jump right into the Flow Designer and get to it.

To begin, let’s click on the New button and select Action from the drop-down list.

We will give our new Action the name Clear Password From Task, and give it a single input, the task record that contains the password variable.

Since all we want to do here is to clear the value from the password variable, there is no need for any outputs, so we will just add a single Script step and insert the following code:

(function execute(inputs, outputs) {
	var task = inputs.catalog_task;
	task.variables.account_password = '';
	task.update();
})(inputs, outputs);

For that to work, we need to map the task record from the Action inputs to the script step’s inputs.

And that is all that there is to that. At this point, all we need to do is to Save and Publish our new Action and then we can jump back into our Subflow and use it in our next step.

*Using our new custom Action to clear the password variable*

Now all we have to do is to assign values to the Subflow outputs and that should complete the successful branch of our Subflow. Then we will need an Else condition to handle the possibility that the task was not completed successfully. But first, let’s wrap up the successful branch by assigning values to the Subflow outputs.

Here we run into a bit of a snag, as you cannot use the password value pill to populate the password output because the password output variable is a 2-way encrypted value and the password value pill is a simple string. To solve that problem, we resort to scripting, with the following code:

return fd_data._3__get_catalog_variables.account_password

This may or may not work — we will have to try it. If it doesn’t properly convert, then we will have to come up with something else. But let’s give this a shot and see what happens.

So now all that is left is to assign the Subflow outputs in the event of a failure. We do that under an Else condition, and grab the reason from the task’s closure notes.

*Setting the Subflow outputs for failure condition*

Once we Save and Publish our new Subflow, we can jump back into the Service Catalog and place another order to try it out. This time, we will select Active Directory from the list of types so that we can drive the process through our new Subflow and see what happens.

After clicking on the Request button, we are brought to our new Request record.

Clicking on the item will bring us to the Requested Item record.

At this point, we can see that something went terribly wrong somewhere along the line. The item is sitting at the Closed Incomplete state, and we never even got the chance to work the manual task that should have been created by our Subflow. That’s definitely not good. Well, that’s obviously not an optimal outcome for our test, but it should make for a fun debugging exercise for our next installment!

Service Account Management, Part IX

Posted on December 28, 2022 | by snhackery

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

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 ServiceNow Subflow, as that is what our calling Action requires.

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.

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.

Service Account Management, Part VIII

Posted on December 12, 2022 | by snhackery

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

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.

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.

Service Account Management, Part VII

Posted on December 7, 2022 | by snhackery

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

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.

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.

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.

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.

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.

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