...
By design each Filenize action is a Queueable, this is slower than running the api’s directly in Apex. This is to prevent hitting DML/Callout limitations.
Executing a Queueable does not start the process directly, the process waits until Salesforce has the resources needed for execution.
Queueables are slower on sandboxes than on production orgs. This is Salesforce’s way to limit resources used.
Since each action initiates an asynchronous process. The result of that process is not usable in the next consecutive process. For folder creation actions we do provide a direct output. As the new relative url is already known prior to the execution.
Queueable Groups
Queueable Groups is new in version 2.5. 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 multiple flows - different queues independent to each other - are 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 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.