Automate This! — Gather Information from Experience Cloud Users with Flow

How can we collect provider data efficiently?

At Gaggle, we help provide therapy and coaching to students. In order to do this, we contract with providers. Once we’ve added a provider to Salesforce, we update their session preferences. These preferences are how we match providers and clients to ensure the best match and best case scenario for the student.

Prior to Salesforce, we asked the providers to fill out a Google Sheet with the necessary information and then manually entered their preferences into our app. Once we moved to Salesforce, I wanted to increase our team’s efficiency and productivity by having the providers update Salesforce themselves by adding their preferences when they log in to Experience Cloud, using a login flow.

However, we don’t want them to have to fill in their preferences EVERY time they log in, so I needed to find a way to only have it run the first time they log in.

Use a login flow to collect information from users

This solution is created using a custom field, a screen flow, and a login flow.

The first thing you need to do is create a custom field on the User object to determine if the Partner User has completed the login flow.

After the field is created, your next step is to create a screen flow that runs in System Context to allow a user to update fields on their Contact record. We need to allow the flow to run in System Context because we don’t want to give them full Read/Write permissions, but the flow needs to be able to update their User record.

Your final screen flow should look like this:

To begin building your login flow, add a Get Records element to get the Contact record of the user who is running the flow. The $User global variable allows you to reference information about the user who is running the flow. In our case, it’s referencing the provider who is logging in to Experience Cloud. Each Partner User in Salesforce has a related Contactrecord which is how the Partner User was created. We want to update fields on the Contact record for the provider, so we need to do a Get Records on the Contact object.

After you get your Contact record, add a Decision element to verify the record was found and to see if the user has already completed the login flow. If the Contact record was not found OR if the Initial Login Complete field is TRUE on the User record, the flow will end.

Next, we’ll gather the information you want the user to update. My first screen element is a Welcome Screen. This uses a display text component and shows an image.

After the Welcome Screen, I added another screen element where the provider can update their name and add their mobile phone and mailing address. For each component I added to the screen, I prepopulated it with the information already saved on their Contact record. This is an important step as it keeps the user from having to reenter information we already have about them.

In the last screen element, I ask them to update their session preferences using standard input components. We use this data to match them with clients.

After you’ve gathered the data you want from the user, add an Assignment element to update the fields on the Contact record. For the Variable side, I used the record from the Get User Contact element, then I searched for the first field I want to update. I then used the Equals Operator and added the API Name of the component from the screen element that I want to assign to my Variable (field) on the Value side.

Next, add an Update Records element to save the previously updated fields to the Contact record, from the Get User Contact element.

Our last flow element is another Update Records that sets the Initial Login Complete field to TRUE on the User record. We used the $User global variable to reference the ID of the provider.

When you save your flow, click Show Advanced and change the setting to run the flow in “System Context without Sharing—Access All Data”. Again, we need to allow the flow to run in System Context because we don’t want to grant them full Read/Write permissions to the User object, but the flow needs to be able to update their User record.

Before activating your flow, you want to test/debug it to make sure everything works correctly. Because you’re building and testing your flow in a sandbox, you have the ability to debug the flow as another user. This means you can run the flow as one of your Partner Users.

To do this, click Debug and then check the box for “Run flow as another user”. Once you select the checkbox, you’ll be able to search for a user and run the flow as them. If you attempt to run it as yourself, the flow will simply end because the Decision element that checks to see if a Contact was found on the User account will not be true, so it will use the Default Outcome path.

After successfully testing, click to Activate your flow.

Once you’ve built and activated it, the final step is to add your new screen flow as a Login Flow for your Partner Profile.

Incorporate login flows in your org!

One of the great things about this solution is its versatility. If I want to have our providers verify and update their preferences twice a year, all I have to do is set the Initial Login Complete field to FALSE for all Active Providers and the flow will run again the next time they log in.

You can also create different login flows based on different user licenses and profiles. This means you can have a different flow for Customers, Partners, and Internal Users, for example.

I hope you find this solution useful and can find a way to incorporate login flows in your org! If you have any questions, feel free to reach out to me on LinkedIn.

Resources

• Trailhead: Build Flows with Flow Builder
• Trailhead: Flow Testing: Step-by-Step
• External Site: Automation Champion: Restricting Login Flows to Execute Only Once!

Want to see more good stuff? Subscribe to our channel!