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

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.