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