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