...
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
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, 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