Welcome to another post in the “How I Solved It” series. In this series, we do a deep dive into a specific business problem and share how one #AwesomeAdmin chose to solve it. Once you learn how they solved their specific problem, you’ll be inspired to try their solution yourself! Watch how Jenn Taylor tackled the request to let an Experience Cloud user upload a photo to Files and have that photo show up in a rich text field on their contact record.
Many of our clients are in the human services field, and they like to have a photo of the person they’re working with to show prominently on their contact record. Obviously, they can put a photo into a rich text field, but that means getting the person to send a file via email or upload it somewhere, downloading that file, editing the contact record... Not a big deal for a few records, but a lot of work when your caseload is in the hundreds.
These same clients often use Experience Cloud to provide a self-service area for the people they work with. It’s easy to upload a file in Experience Cloud, but that file can get lost in the full list of files and this option doesn’t really solve the problem. We’ve been asked many times to let an Experience Cloud user upload a photo of themselves and have it appear in a rich text field on the contact record without any further effort from the case worker—and with flows, we can!
First, I set up my Contact record to contain the rich text field that will display the photo, and a field that lets me easily identify exactly which File record has the photo in it.
Then, I created a screen flow to prompt the Experience Cloud user to upload their photo. The logic in the flow lets us capture the ID of the uploaded Content Document and Content Version, and construct the underlying HTML that populates the rich text field. It may sound complicated, but it really isn’t!
Finally, I embedded the screen flow in an Experience Cloud record page so that users can upload their own photo and share it with their caseworker.
Using the screen flow embedded in an Experience Cloud page, a program participant can upload their photo and share it with their caseworker. This reduces the burden on internal staff by minimizing how many steps it takes to accomplish their goals.
On the technology side, implementing this flow helped my team understand more about how Files work under the hood—using Content Document and Content Version records to access and embed the image. It let us work directly with populating formatted rich text fields, which comes in handy for a number of situations. And, it helped us grasp how screen flows work in Experience Cloud, which adds a lot of rich functionality to any Experience Cloud deployment.
When you put these elements together, you get a fun way to move pictures around. But when you take them apart, you gain tremendous power to automate just about anything to do with files. For example, we modified this solution to allow easy capture of the date that required files were uploaded, dramatically reducing the data entry time for staff who deal with hundreds or thousands of applications that each require several files to upload.
Keep reading for all of the details and step-by-step instructions for this solution.
Add the following fields to your object.
The overview of my screen flow is shown above. I am first confirming that I get the information I need (Contact ID from the Experience Cloud page, in this case) and then determining which of three screens to show: a “thank you” message, our main uploader, or an error screen.
This part of the documentation focuses on the screen flow setup. Step 3 shows setting up the file capture itself, and Step 4 shows the processing logic.
You’ll need several resources to make this work, outlined in detail below. Create all new resources in the toolbox, under Manager, by clicking New Resource.
To construct this solution, you have to know which Contact record you want to attach the new file to and display the uploaded photo within. In the Experience Cloud builder, as long as you’re using a record page, you can pass the ID of the Contact record into a Flow variable. So, you’re setting up this variable to anticipate embedding it into Experience Cloud.
The key to making a photo display in a rich text field is having the Content Version ID of the uploaded file. So, you create a variable to contain it after the upload process. This isn’t strictly necessary, but it makes our lives much easier.
The file uploader available in screen flows will return the IDs of the uploaded files (Content Documents) and Content Versions, but always as a list (collection). So, you’ll create a collection variable to contain the results, even though you’re only going to allow a single file to be uploaded in the flow.
The rich text display needs to know what type of file it’s displaying so that it can correctly generate a preview. This variable contains that information to help in our final step, the display formula.
This is where you bring it all together into the formula that actually displays the uploaded file in your new rich text field. It’s an HTML image tag that references the Content Version ID and the type of file (resources you created above). Note that they are referenced in the formula, so if you changed the names of the resources, you’ll need to change them in the formula, too.
Note: When doing a cut and paste of the formula into Flow, please ensure all quotation marks are straight quotations and not curly quotations. Otherwise, it will not work.
IMPORTANT: Replace REPLACEME in the formula above with your actual Salesforce domain. From any record page, just grab the part of the URL before “.lightning.force.com”.
The part in red is what I put in place of REPLACEME below. Your URL is unique to your Salesforce instance. Note: If you’re building this in a sandbox, you’ll need to update your flow with your production URL when you move this into production.
IMPORTANT: Getting the URL for the Image tag
The URLs for Salesforce resources change periodically. You may find that this formula works great for awhile and then suddenly stops working, in which case I’d immediately look to the URLs.
To get the URL currently in use for the photo previews, do the following.
In Step 3, we’ll build the pieces shown in the image above: get the contact, decide what screen we need to show, and show the screens.
Now that you have all of the prep work done, you can start to build your screen flow. It’s a best practice to confirm that you have all of the data you’re expecting before jumping right in to process it. So, we’ll take advantage of that to show one of three different scenarios: (1) We have already gotten the photo; (2) We don’t yet have a photo; or (3) Something is wrong and we don’t have all the data we need.
This screen flow is intended to be embedded in a Contact record page. We need to confirm we have the Contact ID and can access that record before going any further. To do this, we use the ContactRecordID resource that we set up in Step 2a to find the full record details and make them available later in the flow.
For this example, we want the user to see a different message once they’ve successfully uploaded their photo. Because it’s not relevant for this blog, I’ve put in some very simple placeholder screens. You might choose to display the photo and a “change file” link, or any other logic that your actual use case demands.
Note that you can use a simple checkbox, look for the presence of data in the Photo field, or use any other type of logic you choose. I tend to capture more information to aid in debugging wherever possible, so having the full Content Version ID can give me more information than a checkbox when I’m trying to troubleshoot permissions or duplicates, for example.
New Decision:
Decision part 1: We have a Contact record and it already has a photo.
Outcome 1:
Outcome 2: Nearly identical, except we want to detect that the Photo CV ID is empty (or no photo exists) this time.
Click + next to Outcome Order to add Outcome 2.
Click Default Outcome and change the label to “No” so that if neither of our outcomes are true, we get an error screen.
Your first decision point—yes, we have a Contact record and yes, it already has a photo—will just show a simple “thank you” message for this example.
Under Components on the left-hand side, find Display Text and drag it into the center panel.
To keep it simple, we want to add another Display Text if we have an error. So, we’re going to jump over the middle decision point for now and knock out the other quick screen before moving ahead.
Under Components on the left-hand side, find Display Text and drag it into the center panel.
Finally, we get to the good stuff! This is where we actually set up our file uploader. Please note that the file uploader is tricky—the variables it shows by default are not the ones you want! You want the ones in Advanced, as explained in the steps below.
When you set this up exactly as shown below, you’ll have a prompt for a community user to upload a single file as a child of their contact record. That file will be limited to just image types (.gif, .jpg, and .png) and, most importantly, it will give us back the Content Version ID of the newly-uploaded file so that we can process it in Step 4.
Under Components on the left-hand side, find File Upload and drag it into the center panel.
IMPORTANT: Expanding the Advanced dialogue box
Still in the “Yes—No Photo” logic branch, this last step of the flow will process the uploaded file so that it’s put into the Contact rich text field. It’s a little unintuitive if you’re not a programmer, but, basically, even though we’re limiting the file uploader to only one file, it will return our Content Version ID in a collection. So, we have to process that collection as if there were more records in it, even though there aren’t.
This step proceeds down the middle of the flow, directly under our Upload Your Photo screen.
As stated in Step 4, even though we know we’re only getting back one ID, Salesforce doesn’t know that. So, we have to process the results of our file upload as if we had a whole collection. That requires a loop.
Use the CVID resource you created in Step 2b for the next step, in the formula that displays the photo, and to populate the Contact field that controls which screen shows up for the end user.
Although we only allow one file to be uploaded, the value is returned in a list so we have to process it in a loop. Assign the value that’s in whatever loop of the collection we’re on; remember, have only one for the CVID resource—that’s the only way this works.
While we have, in hand, the ID of the Content Version, we don’t have any other data about it. So, we have to look it up to populate the File Type.
Note that this is being done in a loop, so it’s extremely poor practice to do this unless you’re 100% sure you’re allowing ONLY ONE file. Otherwise, you risk performing queries in a loop, which is never okay in Salesforce (or anywhere else, really).
This takes place AFTER the loop is over (on the “After Last” line). We set our variables in the loop, and now we need to assign them to the Contact record we’re working with, which we selected at the very start of our flow in Step 3a.
Variable 1: Contact from Find_Related_Contact_Record.Photo__c [equals] DocumentURL
Variable 2: Contact from Find_Related_Contact_Record.Photo_CV_ID__c [equals] CVID
This is the last step in the flow! You made it through the hard part! All this does is tell Salesforce to actually write the updated fields (from Step 4d) onto the Contact record we found at the very start of this process in Step 3a.
Now is a really good time to pause and celebrate making it this far!
This last step is really just icing. And don’t worry, it’s very simple! If you already know how to embed a screen flow on a record page in Experience Cloud, you can skip ahead to the testing.
Since we’re assuming that you already know how to set up Experience Cloud and how to set up permissions and visibility, we’re going to skip the how-to on creating a new record page for the Contact object. This example is working with a Contact Detail page that was already set up.
In Experience Cloud Builder, on Pages, we’re working with a Salesforce object page called Record Detail Layout.
Our page has a custom tab set up, and I created a new tab just for this flow called “Photo”. I’ve embedded a Flow component on this tab, as shown in the screenshot below.
This step links the flow you created above to the record page. It uses the Input variable you set up in Step 2a. Remember when you checked the “Available for input” box on the ContactRecordID resource? That’s what allows the Flow component to pass the Record ID into your screen flow.
Please note that it is beyond what I can tackle in this article to address all of the permissions issues and things that could stand in your way in a Customer Communities license setting. So, make sure the user you’re testing with can actually edit their own contact record and upload files before testing your new Flow-based solution.
Log in to your community as a user. Upload a file, and you should get:
Congratulations! You’ve learned a lot about screen flows, flows, Content Documents, and Content Versions—and how it all works with Experience Cloud. Have fun with your new expertise!
Welcome to another “How I Solved It.” In this series, we do a deep dive into a specific business problem and share how one Awesome Admin chose to solve it. Once you learn how they solved their specific problem, you’ll be inspired to try their solution yourself! Watch how Paolo Sambrano operationalized data collection using […]
Welcome to another “How I Solved It.” In this series, we do a deep dive into a specific business problem and share how one Awesome Admin chose to solve it. Once you learn how they solved their specific problem, you’ll be inspired to try their solution yourself! Learn how Katie Villanueva combines Flow, Prompt Builder, […]
Welcome to another “How I Solved It.” In this series, we do a deep dive into a specific business problem and share how one Awesome Admin chose to solve it. Once you learn how they solved their specific problem, you’ll be inspired to try their solution yourself! Watch how Dee Ervin searched unsearchable field data […]
