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

Discussion

Discussion

Why limiting workflow activities increases compute demand of process automation

posted on August 3

Scenario: Customer is limited on how many tasks a workflow can do at once.

So Customer creates more workflows and rules just to manage the status of the work completed so they can restart the workflow sometimes doubling or tripling the total activities required to complete the task and putting more pressure on an already strained rules server by querying the same data, running diffs, and/or temp storing duplicate data.

They still manage to compute all the work they planned to do at once, but the workload on the server has increased for accomplishing the same goal.

0 0
replied on August 4

I agree. 

Working around the limits, just means creating multiple smaller workflows, which is more difficult to develop, test and troubleshoot.  In the end this still runs the many activities required but many, many more rules to updated and maintain cloud Table data to keep track of where it might have left off. 

Use Case:  Laserfiche Cloud Human Resources employee records repository

Primary Limitation Driving the Design

The most significant limitation addressed by the solution is the need to manage a very large employee-manager hierarchy while remaining within Laserfiche Cloud lookup table and workflow processing limits. This is why the design uses multiple specialized workflows rather than a single end-to-end workflow, ensuring scalability, maintainability, and reliable processing of employee records.  Below are not all workflows implemented.  HR systems are ever changing as employees come and go from the organization.  Big limitation with the access rights workflows is that they all have to run multiple times on schedules as workflow cannot access the LF Cloud Accounts area.

  • Centralize all employee records in a secure cloud repository.
  • Provide controlled access to HR, Legal, Executives, and Managers.
  • Digitize historical paper employee files through bulk scanning and automated import.
  • Automate folder creation, metadata assignment, document routing, and security assignment.
  • Allow managers to view only employees they supervise.
  • Support ongoing electronic document submission through controlled approval workflows.
  • Integrate with enterprise Single Sign-On (SSO) through an Identity Provider

 

Employee Folder Creation Workflow (for 50-60k employee folders)

Purpose:

  • Automatically create employee folders when new employees appear on management relationship files.

Process:

  1. Read employee roster.
  2. Verify if employee folder exists.
  3. Create missing folders.
  4. Apply security and metadata.

This prevents manual repository administration.

Manager Security Assignment Workflow

Purpose:

  • Dynamically assign managers access only to their direct reports.

Process:

  1. Read Manager-to-Employee relationship file.
  2. Remove outdated manager permissions.
  3. Apply updated permissions.
  4. Maintain least-privilege access.

This workflow is critical because Laserfiche security cannot automatically maintain manager hierarchy relationships without automation.

Manager Shortcut Generation Workflow

Purpose:

  • Create personalized manager views.

Process:

  1. Identify employees assigned to a manager.
  2. Create shortcuts within manager folders.
  3. Remove obsolete shortcuts.
  4. Present managers with only their staff records.

This improves usability while maintaining centralized document storage.

Employee Classification Change Workflow

Purpose:

  • Handle employee movement between populations (Employee, HR, Executive, Legal, etc.).

Process:

  1. Compare uploaded employee roster to repository.
  2. Detect classification changes.
  3. Move documents and folders.
  4. Update security.
  5. Remove obsolete folder structures.

Without this workflow, administrators would need to manually reorganize records.

1 0
replied on August 4

Thanks for chiming in with examples! The situation I ran into yesterday was a delay every 100 form task assignments (by workflow). The customer asked why it stopped and to give them a brief answer I just let them know there is only so much compute available per hour. 

The real reason it was waiting an hour, was because it was designed to start over every 100 tasks, check to see which tasks it had already assigned and skip the data prep activities in order to reduce the total activities that would be generated if it did every employee in a single shot.

So what was actually happening on the backend instead of waiting for more compute to be available was that it was maxing out the server for about an hour processing nothing just to stay under the max activity limit by the time it touched every employee.

I looked at this and thought well I could just build a join query to prevent pulling already processed results, but join queries are not allowed in Cloud Rules. Then I thought I could do a temp table and realized I would probably create just as much extra work as the current design.

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

Sign in to reply to this post.