Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Next »

Architecture

TODO: Topics to work out

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.

Enter Flows

With Flows it’s now possible to automatically create and pin folders in Salesforce, and more. i.e. creating an account folder on each new account or creating a contact, under the account folder. The tools provided also makes it possible to pin the folders automatically, meaning that when the specific account record is opened, the correct folder opens with it. The SharePoint instance name is needed to use any automation that comes with Filenize.

Pinning is the Filenize term for pinning a SharePoint folder to a Salesforce record. Everytime you open the Filenize component it will automaticly find the right folder for you based on the current record

[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 Package. Select Create and Pin a SharePoint folder. There are 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 (example, may differ for your solution):

  • Folder Name: Field Reference => [Account].Name

  • Pin to Record: Boolean => true

  • Record Id: Field Reference => [Account].Id

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

  • Server Relative URL: String => “/Demo/Accounts”

Save and activate the process builder. 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.

[IMG]

  • No labels