| Info |
|---|
Queueable Groups is new in version 2.5. Visit or our App Exchange page to upgrade if you have an older version. |
Queueable Groups allows allow you to automate multiple queues in a serial mannersequentially. A flow using Filenize is already executing executes all actions in a queue one after each other, but with another. However, when multiple flows - , each representing different independent queues independent to each other - , run concurrently in parallel mode. With , they may not follow a strict order. Queueable Groups you can enforce enable you to impose order, ensuring that one queue to wait waits for another queue. The queue that was created first is then will be executed first (FIFO)., adhering to the FIFO (First-In-First-Out) principle
Example use case with Queueable Groups as the solution
Scenario: You have different flows to create for creating a hierarchy on at both the Account and Opportunity record level. This consists of levels, involving two separate flows. Running When running the flow on the Account and directly on the Opportunity level will run , the queues in parallel mode. Especially run concurrently, especially if the account flow is large extensive and takes some time to complete-consuming. This situation can cause issues lead to problems when the opportunity folder is dependant on the account folder. In this case you want to use Queueable Groups on both the account and opportunity flow. Best 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 provide use the account id Account ID as the Queueable Group identifier, as that this value is available for both on the account Account and opportunityOpportunity. Now, the opportunity Opportunity flow will patiently wait patiently until the account 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 behaviour behavior can differ vary depending on how the way the actions are triggered. Below a couple of scenario’s and the expected behaviour. The , we outline a few scenarios and their expected behaviors. These scenarios assume a DML flow is configured , with only 2 records exist with the name two records named A and B, the . The flow is simple with , consisting of only 3 three actions: Create folder, Share folder, and Unshare folder, or simply labeled as X, Y, Z. (Note: The order of the actions inside within the flow is always serial, sequential; we are looking at examining the order of multiple flow executions and how they work togetherinteract).
Non Grouping
The Commit action is used at the end of the flow without using a Queueable Group.
...
Due to the nature of flows handling bulkified bulk data, the execution order is serialsequential, but by processing each action in within the flow for all records in the DML call before continuing moving on to the next action . (A:X > B:X > A:Y > B:Y > A:Z > B:Z). Actions These actions are within one a single queue.
Both A and B actions are visible in the Diagnose Flow UI because the dependancydue to their dependency.
Filenize skips consecutive steps if an error occurs in the previous one, but this applies only the to actions with the same record reference.
...
The actions run in their normal order, but each flow in their operates within its own queue, causing the two allowing them to run in parallel.
The actions are only visible on record A due to no dependancyUpon the absence of dependencies.
In case of an error, all consecutive actions inside within a queue are skipped.
NOTE: Running the same process twice at the same time can cause concurrently can lead to SharePoint lockup issues. i.e. Trying , such as attempting to write to an existing folder when it’s while it is still being written.
Scenario 003: Two DMLs for record A and B
...
Scenario 004: Two DMLs in a separate transaction for record A
The actions run in their normal order, but each flow in their own queue, causing the two to run in parallel."
The actions are only visible for
...
their respective records; they are not dependent on each other."
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 behaviourbehavior. Multiple records in one DML always have a dependancy dependency with each other. Group or no group, whether grouped or not.
Scenario 006: Two DMLs for record A
The actions run in their normal order, but each flow in their its own queue, the . The last queue waits until the first one is done before running. Making , making the process serial.
The actions are only visible on record A due to no dependancydependency.
Upon an error, all consecutive actions inside a queue are skipped.
NOTE: Beware of the “Maximum "Maximum stack depth has been reached.“ " error. See considerations above.
...
The actions run in their normal order, but each flow in their its own queue, the . The last queue waits until the first one is done before running. Making , making the process serial.
All actions are visible for both records because of the shared queueable group. This causes creates a dependency between the two to have a dependancyrecords.
Upon an error, all consecutive actions inside a queue are skipped.
NOTE: Beware of the “Maximum "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 dependant dependent on each other. Best practice is to use a value that makes sense for the dependancy. I.e. You dependency. For example, you can reference the account id ID as the group for your account, opportunity, and quote flows. Making sure , ensuring that the opportunity and quote folder creation flows only run after the account flow is donecomplete.
Scenario 008: Two DMLs in a separate transaction for record A
The actions run in their normal order, but each flow in their its own queue, the . The last queue waits until the first one is done before running. Making , 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 "Maximum stack depth has been reached.“ " error. See considerations above.