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