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



[Improvement Request] Business Process Modeller - Validation, Gateways and Conditions

posted on December 2, 2019 Show version history

Hey team, 

Back again with another user experience improvement request. This time, we're looking at Gateways and Conditions.

My biggest adversary working with Laserfiche Forms: Terminated Processes.

It should be more difficult to terminate a process, but it is just so damn easy. ;)

Two standout things that lead to problems with terminating processes:

  1. Variables used in gateway conditions not being validated (or persisting when changed).
  2. Wrong gateway type / gateways being improperly configured in the first place.

The first one is a big one. Variables get changed by form designers all the time, and they have a huge impact on processes behind the scenes. There are some activity types that are protected against changes.

For example, in the front end if you rename an email address variable, the changes you make will pass through to certain activity types where those variables might be used. For example, the Email Activity "To:" field. 

This seems to be because the Email Activity uses what I refer to as "variable tokens" to represent variables in some parts of the business process modeller interface.. 

Personally, I think it would be great to see this approach to "variable tokens" expanded to be used in other parts of the business process modeller.

That way if a variable is updated/changed in the front end, those changes can be automatically reflected in the back end, too.

Now, if a variable was deleted, it could grey out and fail validation just like when a task that has been assigned to a disabled or missing user does.

It seems the current "token variables" I mentioned earlier are also subject to some type of additional validation. This is great because it brings potential issues to the surface pretty quickly, allowing you to prevent terminations and/or troubleshoot when changes have been made to a form. Useful when designers have had a free for all with the variables.

So to see this approach to using variables used more widely throughout the designer would be a very welcome improvement to the user experience.

In addition to "variable tokens", it would also be great if validation could be split into two types.

  • Simple validation (current).
  • Advanced validation (new).

Advanced validation would take longer, but it would actually test that every variable used in the process actually exists and if they don't, highlights which activities have been improperly written or configured.

Classic examples - gateway conditions and emails!

So any improvements there would be great, and really appreciated.

Lastly, is the Gateway activities in general.

  • It would be REALLY appreciated if validation could be improved for gateways. Specifically that it could check if a gateway was properly configured and that the variables used in conditions exist.
  • The ability to change a Gateway from one type to another (via right click or via the details pane?).
  • Better documentation, examples and help information on gateway pages would be certainly welcome, too. I think I'll elaborate a bit on this..

As an example: for a Message Start Event there is this Help Icon "?" that displays the following:

But for Gateways, you get no "helper icon", but instead, depending on which type of a gateway you selected, a description for method of use.. 

This message specifically outlines what happens if you use the gateway to split. But it does not explain what happens when you use it to merge. Even better is the Parallel Gateway:

She gets nothing at all - even though, this is the gateway you want to use when you want a process flow to wait until all conditions are met before proceeding to the next step. Which also raises the question - why allow Parallel Gateways to have outflows conditions set at all? Shouldn't that raise an error during validation (to help educate the user on the gateway type)?

Some of these observations are just little things that get mentioned to me by users, or through my own experience. If they can be fixed, that's great. If not, understandable.

Does anyone else have some things they'd like to mention?

2 0
replied on December 2, 2019

Love the suggestions Kris. I am not sure what version you have been using, but for a while now you have not been able to set conditions on Parallel gateways. I can't remember which version that was removed, but it has been. There is still not a description for Parallel gateways though.

What you describe with 'variable tokens' is similar to how Workflow currently behaves when changing a token.

The ability to change a gateway type goes along with another request I have to be able to change a field type when on the Layout tab.

0 0
replied on December 2, 2019

Hey Blake, thanks for your feedback. Regarding the parallel gateways, you are correct that the "outflow controls" have been removed from the details pane however in the process modeller, but you can still successfully validate a process where conditional outflows are connected to the Parallel Gateway.

Example below:

I sometimes come across processes where the user duplicates a bunch of activities (thanks to the awesome new copy+paste functionality) and doesn't realise the type of gateway they're using. They can't work out why their conditions which were set at the outflow path level aren't working/triggering as expected.

What customers love about Laserfiche is that it for the most part really helps you avoid making these types of mistakes most of the time. So hopefully raising these little oddities here we might get the quirks added to a dev list somewhere.

+1 to your idea on changing the field type in the layout view. I'll take a wild guess, and assume the idea stems from forms you've come across where the user has used plain text fields instead of email fields or number/currency fields. Am I right? Haha.

0 0
replied on December 2, 2019


I understand what you mean now. Good catch on the path conditions without having the gateway selected.

The email field is just one example, but if you've noticed you can switch a field type when using a table without any problem so I'm not sure why the same convenience isn't available outside of a table.

1 0
replied on December 2, 2019

Agreed! I don't want to dilute the suggestions too much but I do have one that's nagged me for awhile.


Suggestion: Allow multiple starting types for a process. For example, the primary way of starting a given process is a Message start event with a starting form, but an alternative path is to have workflow start the form and pass all the starting parameters in.. any usually when we want to do this we're starting not quite at the very beginning. There should be a way to have at least one of each type of starting event so workflow could call it and start somewhere OR have a starting form. In some cases, this has caused us to use two identical processes. Here would be something resembling the desired capability:


1 0
replied on December 2, 2019


You can accomplish what you are asking for by having gateways after the message start event and evaluating (usually based on a variable value) if it was started by workflow.

2 0
replied on December 2, 2019

Like Blake said, you can actually still do this without two separate starting points. A Message Start event can still be initiated by Workflow, the basic "Start Event" just doesn't have a form attached to it.

I have multiple processes that can start either way; I just pass in a specific value for a hidden variable when it is started by Workflow, then as Blake describes, a gateway looks at that value and determines with path to take (i.e., user-initiated vs automated).

1 0
replied on December 2, 2019 Show version history

Today I learned! Haha. Thanks!

EDIT: To be fair though, Jeremy's idea would still be more user friendly (in case any devs are reading). So +1.

0 0
replied on December 2, 2019 Show version history

Hey all great workaround! I'll keep that in mind.

EDIT: Question though, how do you do that if it's a public form that normally would be started from a initial submission form? Doesn't what you suggest require assigning a task as one of the paths?

0 0
replied on December 2, 2019 Show version history

I currently use the approach I describe specifically with a public form. If you pass the variable value into the first “submission” made by workflow it will work just fine. All you need to do is hide the field on the form where the normal users wouldn’t see it, then that value can be used in any subsequent gateways.

Even though the form is public, I think it will still show as being started by Workflow. Public doesn’t prompt for login, but I believe it still recognizes the user if they authenticate first.

0 0
replied on December 3, 2019

Thanks Jason again for the detail. One follow-up, I can start the process and input all the variables just fine, but how do you get workflow to automatically "submit" the initial submission form? Populating variables, no problem, but what have I missed with having workflow actually perform that initial submission step? I've only ever had success doing that by an actual user? Are you saying if I populate all the variables on the initial submission form from workflow it'll accept that as if a user clicked Submit on that form?

0 0
replied on December 3, 2019

If you use the "Invoke Business Process" activity, it will behave similar to a user submission with whatever values you provide in the workflow.

The key difference is it will not include the client-side validation, so you need to make sure you're setting all of your required fields.

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

Sign in to reply to this post.