Queueable Groups

Queueable Groups allow you to automate multiple queues sequentially. A flow using Filenize already executes all actions in a queue one after another. However, when multiple flows, each representing different independent queues, run concurrently in parallel mode, they may not follow a strict order. Queueable Groups enable you to impose order, ensuring that one queue waits for another. The queue that was created first will be executed first, adhering to the FIFO (First-In-First-Out) principle

Example use case with Queueable Groups as the solution

Scenario: You have different flows for creating a hierarchy at both the Account and Opportunity record levels, involving two separate flows. When running the flow on the Account and directly on the Opportunity level, the queues run concurrently, especially if the account flow is extensive and time-consuming. This situation can lead to problems when the Opportunity process depends on the completion of the Account process. In such cases, it is advisable to utilize Queueable Groups for both the Account and Opportunity flows. A best practice here is to use the Account ID as the Queueable Group identifier, as this value is available for both the Account and Opportunity. Now, the Opportunity flow will patiently wait until the Account flow has completed all its actions.

Considerations when using Queueable Groups

The Filenize component may take longer to load on the record if a dependent queue is currently running. Referring to the example above, the user who created the opportunity must wait until the account queue is fully executed. This delay could potentially lead to confusion for the end user.

Also, take into account the limitations associated with Queueables. In developer editions or trial orgs, these editions only allow a maximum depth of 5 queues. A queue within a group waits for other queues in the same group to complete by re-queuing itself until it's the queue's turn. Due to this behavior, it's possible that the process reaches the 5-queue limit before the actual processing even begins. When this happens, you'll encounter the error message "Maximum stack depth has been reached."

Order of Execution

When using Filenize actions, the order of execution and behavior can vary depending on how the actions are triggered. Below, we outline a few scenarios and their expected behaviors. These scenarios assume a DML flow is configured with only two records named A and B. The flow is simple, consisting of only three actions: Create folder, Share folder, and Unshare folder, or simply labeled as X, Y, Z. (Note: The order of actions within the flow is always sequential; we are examining the order of multiple flow executions and how they interact).

Non Grouping

The Commit action is used at the end of the flow without using a Queueable Group.

Scenario 001: DML includes record A and B

• Due to the nature of flows handling bulk data, the execution order is sequential, processing each action within the flow for all records in the DML call before moving on to the next action (A:X > B:X > A:Y > B:Y > A:Z > B:Z). These actions are within a single queue.

• Both A and B actions are visible in the Diagnose Flow UI due to their dependency.

• Filenize skips consecutive steps if an error occurs in the previous one, but this applies only to actions with the same record reference.

Scenario 002: Two DMLs for record A

• The actions run in their normal order, but each flow operates within its own queue, allowing them to run in parallel.

• The actions are only visible on record A due to the absence of dependencies.

• In case of an error, all consecutive actions within a queue are skipped.

• NOTE: Running the same process concurrently can lead to SharePoint lockup issues, such as attempting to write to an existing folder while it is still being written.

Scenario 003: Two DMLs for record A and B

• The actions run in their normal order but each flow in their own queue, causing the two to run parallel

• The actions are only visible for their own record, they are not dependant on each other

• Upon an error all consecutive actions inside a queue are skipped

Scenario 004: Two DMLs in a separate transaction for record A

1. The actions run in their normal order, but each flow in their own queue, causing the two to run in parallel."

2. The actions are only visible for their respective records; they are not dependent on each other."

3. Upon an error all consecutive actions inside a queue are skipped

Grouping

The Commit action as a Queueable Group is used at the end of the flow.

Scenario 005: DML includes record A and B

• Same as the non-grouping behavior. Multiple records in one DML always have a dependency with each other, whether grouped or not.

Scenario 006: Two DMLs for record A

• The actions run in their normal order, but each flow in its own queue. The last queue waits until the first one is done before running, making the process serial.

• The actions are only visible on record A due to no dependency.

• Upon an error, all consecutive actions inside a queue are skipped.

• NOTE: Beware of the "Maximum stack depth has been reached" error. See considerations above.

Scenario 007: Two DMLs for record A and B

• The actions run in their normal order, but each flow in its own queue. The last queue waits until the first one is done before running, making the process serial.

• All actions are visible for both records because of the shared queueable group. This creates a dependency between the two records.

• Upon an error, all consecutive actions inside a queue are skipped.

• NOTE: Beware of the "Maximum stack depth has been reached" error. See considerations above.

• NOTE: Creating a flow with a static group for all processes will result in a long list within the Flow Diagnose because all actions are dependent on each other. Best practice is to use a value that makes sense for the dependency. For example, you can reference the account ID as the group for your account, opportunity, and quote flows, ensuring that the opportunity and quote folder creation flows only run after the account flow is complete.

Scenario 008: Two DMLs in a separate transaction for record A

• The actions run in their normal order, but each flow in its own queue. The last queue waits until the first one is done before running, making the process serial.

• The actions are only visible for record A due to no dependency, and both transactions are shown.

• Upon an error, all consecutive actions inside a queue are skipped.

• NOTE: Beware of the "Maximum stack depth has been reached" error. See considerations above.