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

Question

Question

Workflow Designer not showing workflows running on their schedule

asked on June 3 Show version history

When checking the schedule and history in the administration console for workflows scheduled to run it shows that the workflows are running.

For example here is a workflow that runs every hour throughout the day and the last time it ran was supposed to be at 11am this morning (about 30 mins ago)

However if we view workflow history in the designer, we see there is no instance showing the workflow ran. The one instance from 8:52 was a manual run because the customer needed to get the workflow going at least once today as none of their scheduled workflows are running

Version 12.0.2503.2695

0 0

Replies

replied on June 3

Is this workflow in single instance mode?

If you look at the schedule's history under Windows Task Scheduler, does it show any errors?

1 0
replied on June 4

No single instance mode.

I checked task scheduler and it showed an error for all the workflows

Seems there is a breakdown in communication between task scheduler and WF admin console since it was not displaying this error and said the workflows started on time.

In the task I could go to the actions and see what file is missing

Sure enough it was not there.

There are 2 workflow folders in the Laserfiche program files folder (not just in this environment, this seems to be a default for the install wizard)

One is called Workflow and one is called Laserfiche Workflow 10.4, both created by the installer, not manually for any reason. Workflow is the only product that has 2 folders and uses a number on one of them. Seems the software is trying to keep 10.4 feature backwards compatibility all through versions 11 and 12.

I checked the Workflow folder and I found the executable it was looking for, then I copied it along with the config file to the Laserfiche Workflow 10.4 folder.

After this I tried manually running some tasks in Task Scheduler and it did start the workflow. This may have fixed it but not sure why we need 2 copies of the executable.

0 0
replied on June 5

Hi Chad,

Bug #595144 is filed for this issue. We will investigate and fix it soon.

3 0
replied on June 6

Just came across this on another system and copied the 2 missing files over again. How am I the only one running into this?

0 0
replied on June 6

I have only upgraded one of my Workflow servers to version 12, but it is in our dev environment, and we don't leave schedules turned on. I'll see if I can recreate the issue though.

0 0
replied on June 9

This is a bug in the installer for the 2025Q2 release where it will not preserve the previously used install folder on upgrades. 

1 0
replied on June 18

We are also experiencing this issue.

0 0
replied on June 18

We're working on a fix. You should be able to re-link the schedules by editing their properties in Windows Task Scheduler and correcting the path in the action to match the current install folder for Workflow. 

3 0
replied on June 19

Previous installations of Workflow seem to install to a versioned folder under Program Files.  eg. C:\Program Files\Laserfiche\Workflow 9.0\

Upgrades would typically find this folder and upgrade without issue, leaving the original version number regardless of the workflow version being upgraded.  One could always manually remove the version number from the folder path during an upgrade to make for a cleaner end result but it was not necessary.

At a certain point (version 11 I believe) fresh installations would no longer create this versioned folder and would install workflow to the generic Workflow folder. eg. c:\Program Files\Laserfiche\Workflow

Upgrading to LF12 appears to install to the non-versioned folder and removes previous versioned folder completely.  The end result is that workflow 12 resides in the C:\Program Files\Laserfiche\Workflow folder regardless of where your previous installation may have resided.

When a workflow is published with a scheduled starting rule, workflow designer creates a Windows scheduled task.  In the action property of this scheduled task the system is directed to call on WFScheduleMonitor.exe found in the workflow path at the time of publishing.  So if you published your workflows under 10.4 AND your workflow was installed to a versioned folder all things worked fine until you upgraded to workflow 12.  Windows Task Scheduler on the workflow server is looking for WFScheduleMonitor.exe where it used to be not where it is currently.  

The short term solution until LF provides a fix is to update the Windows Task Scheduler properties.  This can be done by editing each task or recreating the scheduled starting rules from workflow designer.  Since this seemed unmanageable at scale, I created and attached a PowerShell script to perform these steps quickly and efficiently.  Simply download, rename the .txt extension to .ps1, and run from PowerShell on the workflow server.  Note: You will need to run this as a member of the administrator group on the workflow server in order to have rights to alter Windows scheduled tasks.

3 0
replied on June 19

For some reason we are seeing multiple workflow folders after upgrading to Version 12. Both Workflow and the Authentication Service are doing this versioning thing and most servers have 3 authentication services with different versions.

0 0
replied on June 19

I suspect the multiple workflow folders existed pre-upgrade and Version 12 likely only added the C:\Program Files\Laserfiche\Workflow\ if it was not already present. 

The Authentication Service is considered a common component for several Laserfiche modules.  Since the installer can't be sure that it is not in use by another module during the upgrade, it leaves the existing service in place and adds the new version.  The new versions are backwards compatible so its easy enough post-upgrade to manually disable the older service and set the newest version to start automatically.  If it bothers you to see the old versions of the Authentication Service listed in Windows services you can use the sc.exe utility to remove the older versions completely.

1 0
replied on June 4

I ran into a similar problem when I set up a workflow to run every hour on weekdays.  It turned out that using the two types of scheduling together created a conflict.  When I set it up to run with five separate schedules (one for each day of the week) every hour, it worked (and still works) fine.

0 0
replied on June 5

Hi James,

Could you please provide the workflow server version and the schedule definitions that will produce the problem?

0 0
replied on June 5

The problem existed at the initial implementation which was years ago.  The problem existed when I attempted to have the workflow run Monday through Friday every 15 minutes for 10 hours.  Here is the scheduling that works.

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

Sign in to reply to this post.