Use Case - Clearing Field Values

Sometimse you need a variable to be empty that was populated on a prior task.  Especially if you need to re-trigger lookups or default values.

You can do this on the form itself, but it requires some Javascript, and only occurs after the form is already loaded - so although that might work for lookups, it won't work for default values.

You can do this in Workflow, with just an activity to push back a NULL value into the indicated variables.  But we're adding more complication to the process with at least one, and perhaps multiple, workflow(s) that do nothing but clear a variable value.

It would certainly be a lot easier to be able to populate a NULL value into a variable when you needed to, directly from the Process Diagram.

Use Case - Single Form Solutions / No-Code or Low-Code Solutions

One of the big benefits of how powerful the modern designer is, especially with Field Rules, is the ability to do single form solutions for a process and eliminate much of the code many of us used on the Classic Designer for things like disabling fields in certain situations.  Where the Classic Designer would have required multiple, nearly identical forms, and/or complex Javascript in order to address small differences, the Modern Designer can handle this beautifully with Field Rules.

But Field Rules cannot set variable values, those still have to be set by formulas or lookups or Javascript.  And of course there are limitations with formulas and lookups updating fields that were already populated on a prior task.  When you want a variable to have a different value based how the instance is being routed through the process this especially gets complicated.  Field rules are able now to identify on Step or Stage, but formulas and lookups cannot.  Javascript can do it, but usually require custom HTML elements to populate things like the step name, and now you are needing to write code to address that.

It would certainly be a lot easier to be able to populate values into a field from the Process Diagram to address the routing of the instance, prior to even getting to the form task.

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.