Flows

Architecture

TODO: Topics to work out

• Invocable (https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_annotation_InvocableMethod.htm )

• Queueables (https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_queueing_jobs.htm )

• Logging

• Flow

• Filenize’s implementation

Considerations

• Adding Filenize actions to your flow does not make it final. At the end of the flow you need to run the Filenize commit action. This is to build a queueable chain of actions. Ensuring that the next action only runs if the previous has finished. This needs to be done explicitly due to the asynchronous design of the actions.

  • The chain also skips all consecutive actions if an error has been found. To prevent certain scenario’s, i.e. where a subfolder needs to be created if the parent folder does not exist due to and error

• TODO: All actions in the flow are executed First In First Out. But when using the Diagnose Flow utility that comes with Filenize, there might be some differences.

  • When running a flow for one specific record, you just see the actions related to the record in the UI. Pending and actions in the past

  • When running a flow where multiple records are in one DML call, each action is executed n times per record before continuing to the next action

    • This is standard Salesforce flow and bulkily behaviour

    • We stop all consecutive actions after an error occurred which are linked to the same record. The other actions still continue

  • When running a flow where multiple records are saved, but each in their own DML call, all the actions are

Pro

• Easy to setup for admins and developers

• Includes in-depth diagnose tooling for spotting incorrect behaviour

  • Also includes rerunning certain actions for trial-and-error testing

• Provides out-of-the-box user feedback about it’s progress in the Filenize component

Con

• 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 with 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 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.