Page Comparison

...

• 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’sscenarios, i.e. where a subfolder needs to be created if the parent folder does not exist due to and an 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 behavior

    • 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

...

• Easy to setup for admins and developers

• Includes in-depth diagnose tooling for spotting incorrect behaviourbehavior

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

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

...

• By design each Filenize action is a Queueable, this is slower than running the api’s APIs 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 the 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 URL is already known prior to before the execution.

Enter Flows

...

[IMG]

Create/open an existing new Flow. Select a new Action element within the flow then search for SharePoint to find all the actions that came with the Managed PackageFilenize. Select Create and Pin a SharePoint folder. There are a A couple of properties that allow you to customize the action to your business needs. In our example, we’re going to create a folder on every new account in Salesforce. The following values applies apply (for example, may differ for your solution):

• Folder Name: Field Reference => [Account]{!$Record.Name}

• Pin to Record : Boolean => trueRecord Id: Field Reference => [Account]{!$Record.Id}

• SharePoint Instance Id: String => Your SharePoint Instance Name (i.e. see screenshot above)

• Reset Sharing on Folder (Optionally): Usually this is set to true for root folders with custom sharing

• Server Relative URL: String => “/Demo/Accounts”A fixed path or a reference to a previous folder action

Save and activate the process builderFlow. The above ensures that a new account folder is created and automatically pinned to the account record.

 [IMG]

1.1      Invocable

The Managed Package includes a set of invocable actions to allow admins to automate certain SharePoint actions with Process Builder or Flows. Do note that invocable are useful for simple tasks as creating folders. For complex tasks it’s best to work with Apex directly. The current list is:

• Create and pin a SharePoint folder (as also shown in the example above)

• Create a SharePoint Folder

• Pin a SharePoint folder

• Share a SharePoint folder

• Update metadata of a folder/file

• Upload a file by referencing an Attachment/Content Document/Content Version

• Committing all actions 

1.2      Folder Hierarchy

Creating a folder hierarchy is possible when using Flows in combination of the Managed Package invocable actions. Using the “Create a SharePoint folder” invocable action returns the folder’s path directly, allowing you to use that information to make subfolders. Each invocable is asynchronous and is executed as a queue with the “Commit” action, making sure all the folders are created in the right order.

...

Next Steps

Above was just a short introduction of the “Create and Pin a SharePoint Folder” action. There are many more that allows you to customize your folder hierarchy for your business needs. Check out the Actions page and the Examples page to learn more.