One File, Many Records – Flow Approach by Gidi Abramovich

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!