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