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.