Use Case - Reporting
Very often a requirement of processes I build is that they want reporting functionality. Sometimes this can be met by the built-in Forms reporting functionality. But more often they want the ability to select search criteria that they can change on the fly, which the built-in Forms reporting functionality doesn't really handle.
There are two main ways I handle this. Either a Forms process for the report, with fields that can be changed for the search criteria, and a Stored Procedure on the database to complete the search, or using a BI platform like Microsoft Power BI for the reporting, and these have built-in filter functionality. In either case, this requires database information.
Using the LFForms database directly is not usually a good plan. We don't control that database, and can't guarantee that future changes won't break or remove any customization we do. Additionally, locating specific values on specific processes can be quite tricky. So we usually make and maintain our own databases with Forms calling Workflow to post those insert and update statements.
When the reporting goal is just to list variables on the Forms process, this is easy.
But very often, the requirements also call for a status value, regarding where in the process the instance currently lives. This gets more complicated.
Once again, we could refer to the LFForms database directly, but that is less than ideal as mentioned above.
So we need to have a way for workflow to identify where in the process the instance is at to generate a status value (things like "New", "Complete", "Cancelled", "Waiting for Employee", "Waiting for Manager", "Waiting for Accounting", and many other similar values).
We can have the form itself determine this value. But it isn't as simple as what is the form currently in progress, because those variables only update when forms are submitted, so the Form needs to identify what the step after submission is going to be. Now we're replicating behavior that exists in the Process Diagram once again, and usually as Javascript, which can be complicated. So this is not the best solution.
We can have Workflow determine what stage it is at. This is often what I end up doing. We needed to have Workflow run anyway to make the database update, let's also have it determine the current status. But once again, we're replicating something that the Process Diagram in forms is already doing. This often involves things like determining what the last task completed was, and the action the user took on that task, and listing all the possible combinations to determine what status value applies. This works, but is another potential source of errors if we forget to make updates when changes to the forms process happen, or when unexpected events happen (like suspended or terminated instances, or admin actions on the Monitor page like skipping tasks, restarting tasks, or editing variable values - if the Workflow isn't accounting for these, or having some sort of notification when nothing else matched, it ends up not performing the expected database maintenance).
Another workflow option that is perhaps less error prone is to have a different workflow for every possible option, and then the Process Diagram in the form just calls the appropriate workflow based on where in the diagram it is at. This means you have a bunch of nearly identical workflows. These might be pretty simple (pull variables from the form, post them to the database). But this does mean we have a dozen or so Workflows for a single Forms process, and this adds complexity to maintaining the process that could have been avoided if we could have just set the Status value in the Process Diagram in Forms before we called the workflow to update it in the database.
Being able to set the variable value from the Process Diagram means being able to dictate that status leveraging the routing already in place on the Process Diagram without needing to replicate that routing in the Form or a Workflow, while also keeping the number of required workflows for the process as low as possible.