From Josh Dayment & Ryan Mercer: Improved File Upload in Flow Screens

This Post was most recently updated on: 3/8/23

File Upload Improved is a custom screen flow component that improves upon the basic File Upload screen component in Salesforce Flow. It adds a number of capabilities. Most notably, it allows the user to interact with their file that they have just uploaded.

Credits: Josh Dayment and Ryan Mercer

Features

We have packed File Upload Improved with many features. We are actively developing the component, so feature requests are welcome either in the comments or on GitHub.

View files after being uploaded;
Render existing files that have already been uploaded to a particular record;
Specify accepted file types;
Restrict users from uploading multiple files, or alternatively allow users to upload multiple files;
Require users to upload at least one file before proceeding, and prompt them with a custom message if they do not;
Delete files immediately in the UI;
Allow community users to upload files to records that are not shared with them;
Set the file name of uploaded files;
Control whether files are visible to all users;
Full control over most aspects of the UX; and
an Invocable Apex Action to create ContentDocumentLinks downstream in your flow.

Permission Set

After installing File Upload Improved, it is important that admins assign the File Upload Improved Permission Set to EACH user that will be using the component in a screen flow. We repeat, every user that uses the component in a screen flow MUST have the File Upload Improved permission irregardless of if they are an internal user, an authenticated community user, or an unauthenticated guest user.

If a user receives the error message, “You do not have access to the Apex class named ‘FileUploadImprovedHelper’.”, admins need to assign the permission set to that user.

Sharing Rules and Without Sharing

The File Upload Improved Permission Set gives users access to the Apex Class FileUploadImprovedHelper. It is important for admins to understand that this Apex Class runs in a WITHOUT SHARING context, which means that users can potentially interact with files related to records that they can’t normally access.

In the most basic configuration, users will be able to upload files to records that they can’t access. The component was specifically designed this way to address the need for community users (authenticated and unauthenticated) to be able to upload files to a record that they can’t access. As explained in the File Upload LWC documentation:

“By default, guest users can’t upload files and don’t have access to objects and their associated records.

To enable guest users to upload files, enable the org preference Allow site guest users to upload files. However, even if you enable this setting, guest users can’t upload files to a record unless guest user sharing rules are in place.”

Salesforce provides components a way to publish an optional bypass for the sharing rule restriction, but Without Sharing is required: at a high level, we are encrypting the Related Record Id and passing it into the File Upload component via the file-field-name and the file-field-value. onuploadfinished the class is querying the newly created ContentVersions, decrypting the Related Record Id which has been populated in Guest_Record_fileupload__c, and creating ContentDocumentLinks from the uploaded file to the record.

Now, a more advanced configuration of the component will allow admins to render existing files in addition to allowing the user to upload new files. This too runs in a Without Sharing context, so the user can potentially see and delete files that are related to a record that they can’t normally access. Admins should test their configurations by logging in as a variety of different users to ensure that they are not exposing sensitive files inadvertently.

{!$Flow.InterviewGuid}

When configuring the component in the screen flow, admins will notice a field with this label: {!$Flow.InterviewGuid}. Even though it is not marked as required, admins should ALWAYS populate this field. This field serves as a key to temporarily cache the files in the browser using sessionStorage so that they don’t disappear if users hit a validation error, and are there for users if they come back to the screen.

Because it’s being used as the key, the value in the field must be unique. If there is only one component in the flow with a definitive start and end to the flow, then admins can use {!$Flow.InterviewGuid} which is the unique identifier for the interview.

If there are multiple components in the flow with a definitive start and end to the flow, admins will have to append {!$Flow.InterviewGuid} to make it unique.

If there is a single component in the middle of a loop, admins will have to use a flow formula like…

… and then use that formula in the field.

There’s really no wrong way to do this – it just HAS to be unique. What happens if it’s not unique? Users will resurface unwanted files from the cache at the wrong time. If a user ever sees files that are rendering that shouldn’t be, it is quite likely that the value in this field isn’t unique, and admins need to make it unique!

Invocable Apex Action

File Upload Improved (and the standard File Upload Screen Component for that matter) ask for the Related Record Id by the time the component renders. In other words, in order to upload files to a particular record using either component, the record must already exist in Salesforce prior to getting to the screen with the File Upload component.

What happens if the record (and Related Record Id) doesn’t yet exist? Let’s say you have a Screen Flow to allow users to submit Cases to your team for support. You’d like the option for those users to upload files to provide additional context – maybe a screenshot of an error message?

File Upload Improved includes an Invocable Apex Action for enabling File Uploads without having to pre-create records. You can read all about this functionality HERE>>.

Inputs

Property Name	Data Type	Introduced	Description
{!$Flow.InterviewGuid}	String	v1.4	Unique identifier for this field. You can start by using {!$Flow.InterviewGuid}. If you have multiple of this component type in the same flow, you’ll have to prepend {!$Flow.InterviewGuid} with something else like ‘1’ or ‘2’ to make each component unique. When using the version with a Custom Property Editor this will need to be stored in a string variable and referenced in the combobox in the CPE since global variables are currently not supported in fsc_flowcombobox.
Accepted Formats	String	v1.0	The accepted file types. Enter a comma-separated list of the file extensions (such as .jpg) that the user can upload.
Allow Multiple Files	Boolean	v1.1 – initial commit v1.5 – component disables if not true and a file has been uploaded	Allow the user to upload multiple files. If this is not TRUE, then once the user uploads one file, the file upload component will not allow any additional files to be uploaded.
Deprecated	N/A	v1.3.1	This input is deprecated. Any value set here will no longer impact the function of the component. As of v1.5, the field formerly known as Bypass Community Sharing Rules has been deprecated.
Disable File Deletion	Boolean	v1.8	When this is TRUE, clicking the ‘X’ next to the Files will simply remove them from the UI and the output list, but the Files will NOT be deleted.
Embed on External Website	Boolean	v1.7	If this flow is being embedded on an external website (like WordPress, for example), set this to TRUE. Otherwise, this should almost always be empty of FALSE. From a technical perspective, this switches the component from `lightning-file-upload` to `lightning-input type="file"`. This allows us to bypass some of the dependencies the former has on One.app so that it is externally embeddable. But it comes with certain tradeoffs, most notably the max file size is 3.5 MB though there may be others. You can read about when you might set this to TRUE here >>.
Help Text	String	v1.8	The message that will be displayed in the help text popup.
File Upload Label	String	v1.0	The text on the file upload button.
Icon	String	v1.0 – initial v1.3.1 – the system will now automatically display the correct icon depending on the file type	We suggest you leave this blank. The default LDS Icon that will be displayed next to each uploaded file. Options here: https://www.lightningdesignsystem.com/icons/#doctype. Prepend icon name with ‘doctype:’, ie ‘doctype:word’. Leave blank and the system will display the icon based on the extension type.
Overridden File Name	String	v1.5	The file name of the uploaded files defaults to the actual name of the file. If you’d prefer to override the default file name, you can specify the new file name here. You can do funky things here like using a Text Template (remember to View as Plain Text) or even using a Flow Formula
Related Record Id	String	v1.0	The Id of the record to associate the files with. Be aware that sharing rules are NOT enforced, so the user could be uploading files to a record that they wouldn’t normally have access to. If this field is blank, then the file uploads, but no ContentDocumentLinks are created and the file isn’t related to any records.
Required	Boolean	v1.3.1	Require the user to upload at least one file.
Required Validation Message	String	v1.3.1	The validation message displayed if the user has not uploaded at least one file. The default message is ‘Upload at least one file.’
Set Visibility to All Users	Boolean	v1.5	By default, when an internal user uploads a file, the file is only visible to other internal users (meaning community users can’t see it). If you’d like to make the uploaded file visible to all users, set this to TRUE. When a community user uploads a file, the file is already visible to all users. From a technical perspective, this sets ContentDocumentLink.Visibilty = AllUsers.
Show Existing Files Related to Record Id	Boolean	v1.5	If you’d like to show the existing files associated with the Related Record Id (in addition to the ones that the user may upload), set this to TRUE. Be aware that sharing rules are NOT enforced, so the user could see files that they wouldn’t normally have access to.
Show Files Below the File Upload Component	Boolean	v1.5	By default, the files will show above the File Upload Component. If you’d prefer they be shown below the component, set this to TRUE.
Uploaded File List Label	String	v1.3.1	We suggest you leave this blank. The text on the list of files uploaded. You might find that you prefer to leave this blank, as the UX is obvious.

Outputs

The outputs can be accessed via manual assignment or by referencing the component via the API name directly.

Property Name	Data Type	Introduced	Description
Content Document Ids	Text Collection	v1.0	The Ids of the uploaded files. Store this value in a text collection variable. This collection returns empty for community users – authenticated and unauthenticated.
Content Version Ids	Text Collection	v1.3.1	The Version Ids of the uploaded files. Store this value in a text collection variable.
Uploaded File Names	Text Collection	v1.3.1	The names of the uploaded files. Store this value in a text collection variable.

Developer Notes

We have had a few inquiries on the component not working in Experience Cloud Sites that use Lightning Web Runtime. The standard lightning-file-upload component is not currently supported in LWR due to it being wrapped in Aura as of the Spring 23 release of SF however to get around this you can mark Embed on External Website as true and it switches the component to use lighting-input as the file upload method when doing this you are restricted to the 3.5 MB file size limit but does give you an option for file upload in LWR.

Install

IMPORTANT: This package includes a permission set named “File Upload Improved”. Make sure to assign it to any users to whom you want to grant this upload capability.

Version 2.0.1 1/24/22 Production Sandbox Custom Property Editor

Previous Versions

Version 2.0.0 12/10/22 Production Sandbox Custom Property Editor

Version 1.8.4 11/10/22 Production Sandbox minor fix

Version 1.8.3 9/11/22 Production Sandbox Fix for Content Version ID problem.

Production or Developer Version 1.8.2 3/20/22

Sandbox Version 1.8.2 3/20/22

(click here for Installation Troubleshooting)

Version 1.8 3/12/22 adding help text configuration & allowing file deletion disablement 3/16/22 a bug has been identified, fix on its way

Version 1.7.2 3/1/22 bug fix

Version 1.7.1 1/13/21 (Enhancements)

Version 1.6 12/21/21 (Enhancements)