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



When do changes to Business Process affect active instances?

asked on May 23, 2023

I'm trying to anticipate how necessary changes to my Forms business process will affect instances that are still running.  I understand that if I remove a step that an active Forms process is currently waiting at, it will terminate the process.  However, if I re-order or remove steps in the middle of the process but all active processes have already completed those steps, will the active instances just continue to run?  What about processes that have not reached those steps yet?  Is it a safe rule of thumb that as long as all active instances are at steps that have not changed, it should be safe?

Is there any difference between changes that are introduced by directly editing the business process as opposed to overwriting the entire process in PROD using an imported DEV process? 

I'm somewhat new to Laserfiche Forms and it's all rather murky.  The prospect of accidentally terminating a large number of active processes and being forced to re-enter them is terrifying.

I don't really have the luxury of pausing submissions and waiting for the active ones to process through the system.  I'd also prefer not to rename the current process and assign the URL to an entirely new process since it will create a disconnect between old and new processes for monitoring and reports.

0 0


replied on May 23, 2023 Show version history

Generally speaking, it is safe to change anything that is not currently "in use" but that is not as straightforward as "active/inactive."

First, in this context the only major difference between manual/progressive changes and overwriting with an imported copy is that all the changes occur at once. Changes to a Forms business process will always affect active instances so you do have to be careful.

A lot of this is going to be case-by-case and highly dependent on the nature of the changes, how your steps depend on one another, etc., but there are some general things that can help you decide what you need to do to keep things running smoothly.

That being said, no it is not safe to assume that changes to a step will not cause a problem simply because that particular step is not active in any instance; whether or not it will cause a problem is much more about what specifically you are changing.


As you mentioned in your example, removing a step that is connected to an active task would cause a problem just like if you tried to demolish an overpass while someone was driving on it.

On the other hand,

If you reorder the processes, like adding a new step or diverting things to an entirely different step, it's more like closing the onramp; that alone won't affect the current traffic.

If you change the steps that follow, then you would need to preserve the outflow of the replaced step so it could continue along despite the changes; like leaving the offramp open and/or redirecting it until you get everyone off of the highway.

Depending on the changes, one or both of those concepts may apply.

If you have a step that is no longer active, like if you made the two changes above then waited to clear out all the traffic, then you would be in a safe position for removal.

Basically, you don't have to pause or break active instances to make a change, but depending on the nature of the changes you might need to treat it more like a transition and set up temporary detours and/or delay removal until you can safely wrap everything up.

You also have to be mindful of the bigger picture. Say for example, you remove Step 2 because it's no longer necessary. If there are no instances actively waiting for Step 2, that might be perfectly fine. However, if Step 3 depends on a value that is only collected in Step 2, then you could create a problem for yourself like ripping out a wall before checking if it is load bearing.


The same concept applies to other things as well, like adding/removing fields and variables, changing whether fields are required, etc.

The key difference with fields/variables, is that they are the most likely to affect an entire instance, but the general solution is the same, i.e., making changes in the right order to ensure anything new gets added to all new instances but making sure it isn't required for older instances, and removing dependencies before you remove any field/value.

The important thing to note with field/value changes is that anything you remove will be removed from everything including the history on old instances, and anything you add will be added to everything, but it won't have a value in any instances that are past the point of the process at which the value is set.


Long story short, it's always going to seem a little murky because it really depends on how your process works and the nature of the change; the key is to think about the process as a whole, always evaluate changes in that context, and make the changes incremental when necessary.

4 0


You are not allowed to reply in this post.
You are not allowed to follow up in this post.

Sign in to reply to this post.