You are viewing limited content. For full access, please sign in.

Discussion

Discussion

Enhancement for Forms - Editing Variable Values on Process Diagram

posted on March 12 Show version history

I've mentioned this before, years ago, but I think it's worth mentioning again.

I believe that it would be beneficial to add an additional Service Task option to the Forms Process Diagram to "Edit Variable Values" - really similar to Workflow's "Assign Token Values" activity, where you can set a whole new value, complete simple functions, extract portions of the value using Pattern Matching, and format date and number values - and apply those values back into existing variable values and/or create new variable values as a result.

These are definitely things that can be done using the Workflow Service Task - but that means more workflows to maintain over relatively small changes (which isn't usually a problem, but it is adding complexity to processes, and when you have hundreds of workflows, or even thousands, and need to do things like migrate them to a new server, it becomes a giant pain).

Many of these are things that can be done on the forms themselves, but rarely as a no-code or low-code option, and you are often replicating things done in the Process Diagram (like routing decisions in gateways), so it is more complixity with the process, and another thing that could be accidentally overlooked on future changes.

It would be cleaner to be able to complete these simple changes in the process diagram rather than needing to duplicate functionality in a form, or add complexity with additional workflows.

I'm going to post several use cases in the comments, and I encourage anyone else who would like to see this enhancement to do so as well.

Thank you!

6 0
replied on March 12

Use Case - Formatting Dates

Forms uses a lot of dates, when was the instance started, when did it end, what was date of the last user action, when is this task due, when does this timer expire, etc.  Not to mention any date fields we include in our forms ourselves.

And these can be formatted on the form itself, but that is just a visual item on the form, behind the scenes, that formatting isn't retained (and it shouldn't be really).  But sometimes you really need a formatted date to display in the instance title or when saving to the repository, or things like that.

I'm in the US, so standard date format is M/d/yyyy - but I really prefer to use yyyy-MM-dd or yyyy/MM/dd - especially when saving to the repository.  Bacause a date written as yyyy-MM-dd will automatically be in chronological order when sorted alphabetically.  Which means if I name an instance or an entry in the repository starting with the date formatted as yyyy-MM-dd, those instances in Forms or those entries in the repository are naturally in chronological order when sorted alphabetically.  This is huge, I use it on at least 50% of the stuff I archive to the repository.  But there is no built-in way to format the date.

That means, I need to either have fields on the form itself that populate the date, or at least have those fields there and have Workflow populate them.

I'll usually make three fields for year (formatted as yyyy), month (formatted as MM), day (formatted as dd) so that it's easier to get the full date (yyyy-MM-dd or yyyy/MM/dd) or a partial date (yyyy-MM or yyyy) without needing additional fields.  These will be single line text fields (not date fields) populated by formulas.  This works when I need the start date of the process, but is trickier when I need the end date of the process, since formulas won't re-run on fields that are already populated.

The alternative is to use workflow to populate the dates, a simple workflow can push back the variable values to the Forms instance using the current date token and some simple formatting on the Token Editor - and the date will be whatever day the workflow is called, instead of fixed to just the first time the fields are populated like they would be with formulas on the Form itself.  This works well, but is adding complexity to the process requiring the creation of additional workflows.

It would be nice if directly in the Process Diagram, I could create or update a variable value that stores the current date in whatever format I needed.

2 0
replied on March 12

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.

2 0
replied on March 12

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.

2 0
replied on March 12

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.

2 0
You are not allowed to follow up in this post.

Sign in to reply to this post.