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