Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Queueable Groups is new in version 2.5. Visit or App Exchange page to upgrade if you have an older version.

Queueable Groups allows you to automate multiple queues in a serial manner. A flow using Filenize is already executing all actions in a queue one after each other, but with multiple flows - different queues independent to each other - run in parallel mode. With Queueable Groups you can enforce one queue to wait for another queue. The queue that was created first is then executed first (FIFO).

Example use case with Queueable Groups as the solution

Scenario: You have different flows to create a hierarchy on Account and Opportunity record level. This consists of two separate flows. Running the flow on the Account and directly on the Opportunity level will run the queues in parallel mode. Especially if the account flow is large and takes some time to complete. This can cause issues 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 practice here is to provide the account id as the Queueable Group identifier, as that value is available both on the account and opportunity. Now the opportunity flow will wait patiently until the account flow has completed all its actions.

Considerations when using Queueable Groups

  • The Filenize component will take longer to load on the record if a dependant queue is currently running. Looking at the example above, the user that created the opportunity needs to wait before the account queue is completely done. This might cause confusion for the end user.

  • Consider the limitations around Queueables, developer editions or trail orgs, those editions only allow a max depth of 5 queues. A queue within a group waits for other queues in the same group to complete by queueing itself again until its the queues turn. Because of this behaviour it’s possible that the process reaches 5 queues before the actual process has even started. The error “Maximum stack depth has been reached“ is then shown.

Order of Execution

When using Filenize actions, the order of execution and behaviour can differ depending on the way the actions are triggered. Below a couple of scenario’s and the expected behaviour. The scenarios assume a DML flow is configured, only 2 records exist with the name A and B, the flow is simple with only 3 actions: Create folder, Share folder, Unshare folder or simply X, Y, Z. (Note: The order of the actions inside the flow is always serial, we are looking at the order of multiple flow executions and how they work together).

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 bulkified data, the order is serial, but by processing each action in the flow for all records in the DML call before continuing to the next action. (A:X > B:X > A:Y > B:Y > A:Z > B:Z). Actions are within one queue.

  • Both A and B actions are visible in the Diagnose Flow UI because the dependancy.

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

Scenario 002: Two DMLs for record A

  • 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 on record A due to no dependancy

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

  • NOTE: Running the same process twice at the same time can cause SharePoint lockup issues. i.e. Trying to write an existing folder when it’s 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

  • 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 record A due to no dependency, both transactions are shown

  • 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 behaviour. Multiple records in one DML always have a dependancy with each other. Group or no group.

Scenario 006: Two DMLs for record A

  • The actions run in their normal order but each flow in their 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 dependancy

  • 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 their 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 the shared queueable group. This causes the two to have a dependancy

  • 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 dependant on each other. Best practice is to use a value that makes sense for the dependancy. I.e. You can reference the account id as the group for your account, opportunity, quote flows. Making sure the opportunity and quote folder creation flows only run after the account flow is done.

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

  • The actions run in their normal order but each flow in their 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, 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.

  • No labels