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

TODO: Topics to work out

• One queueable per action

Pro

• Easy to setup for admins

• Includes in depth diagnose tooling for spotting errors

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