Community rock-star Gidi Abramovich responded to ‘One File, Many Records‘ with an implementation he had created using Flow. Gidi volunteered to share his approach as we felt this would be useful as an alternative to managing in Apex. What is represented here is a simplified view into Gidi’s solution…
Scenario
Let us take the example where we have some important Files on the Account object that we want to be reflected on any Case created against that Account. Any time a Case is created, the Files against the Account should be ‘cloned’ (via ContentDocumentLink record, which is the junction object that links files to specific records) to the child Case without duplicating the File itself.
Easy / UI Only Approach
In many situations, it will be sufficient to only view the Files that are associated to the parent Account without actually creating a direct reference to the child Case. In this event, we can use the standard Lightning Record Page feature of ‘Related List – Single’ of type File pointing to the Parent Account rather than the Case. Note here that the parent Account must have the Files related list on the detail page layout for this option to work.
When the Account has Files, they will appear in this Related List.
This approach is shown in further detail here: Don’t Forget this Simple Lightning Record Page Feature.
Solution
In some scenarios, having the Files associated to the child record itself will be required. Here we will demonstrate how to accomplish this using an after-save record-triggered Flow. For our use case, we’ll use an asynchronous path after a Case is created. This is because we don’t need the Files extended immediately upon creation and this will also prevent any issues with the File cloning causing the Case insertion itself to fail.
Next, we collect the ContentDocumentLink records from the parent Account.
Now create a ContentDocumentLink record variable (single) that we will use to create the new links.
And a ContentDocumentLink record collection variable (multiple) to store the new records to create.
Next we will loop through the records (ContentDocumentLinks against the Account), and fill up our single ContentDocumentLink variable. Most important is to set the LinkedEntityId to the Case Id (from the current record that launched the flow).
| Output (New Record) | Input |
|---|---|
| varSObj_ContentDocumentLink.ContentDocumentId | Current Item in Loop.ContentDocumentId |
| varSObj_ContentDocumentLink.ShareType | Current Item in Loop.ShareType |
| varSObj_ContentDocumentLink.Visibility | Current Item in Loop.Visibility |
| varSObj_ContentDocumentLink.LinkedEntityId | Current Record => Case Id |
Assign each CDL record variable to the ContentDocumentLink collection. The loop will repeat this process for us until we’ve gone through all the Account Files.
Lastly, we insert the new List of ContentDocumentLinks against the Case.
The full Flow should look like this:
Result
Let’s test it out. First, add a couple of Files to the Account against which you’ll create the Case.
Now use ‘New Case’ from the Account. Fill in whatever required values may be in place.
Save. Go to the Case that was created – you may have to pause here for a second as you’ll recall we made the File clone Flow on the asynchronous branch.
Verify in the Files related list that all Files from the parent Account were associated to the created Case. Success!
Extension
In Gidi’s real-world implementation, he has built a UI layer on top of this functionality, which allows users to decide at any time which Files they’d like to push/clone to child records. The user is presented with a list of Files against the Parent record in a lightning datatable, from which they select the Files they’d like to clone to the children. From there, he’s calling a subflow with the ContentDocumentLink creation logic similar to what we’ve demonstrated here for record-triggered Flow.
Important Note
You will encounter an exception if you try to insert a duplicate ContentDocumentLink (same ContentDocument tied to same LinkedEntityId). As a result, be careful if you’re doing any sort of logic that may encounter scenario where File is already associated to the record you’re targeting.
Wrapping Up
Many thanks to Gidi for providing his time and expertise to the community. Hopefully this simple demonstration of his approach to File management will be helpful to others and spurn further creativity!
If you created a screenflow or something similar described in the extension part of this article, then for the duplicate error you can create a decision element that you will place after the create CDL, connect it with a fault path. (create CDL –> Decision)
In that decision add a criteria like {!$Flow.FaultMessage} Contains DUPLICATE_VALUE. If true then reroute to a screen element where you can warn the user that he/she choose a file that is already on the target record and then reroute them back to the screen where they can push/clone to child records
At last i would recommend rerouting that decision element to a subflow (if condition is false. i.e default outcome) in which you handle all others errors.
Too bad i can’t add an image in here that would make it easier to read.