Best Practices for Passing Parameters to Public Flows

Similar to Lightning pages, you can add active Screen Flows into Experience site pages, enabling external users to engage with flows. Additionally, by adding a flow to a public page, you make it accessible to anyone viewing the page. In this scenario, in order to work with relevant data, you may need to pass parameters to your public flow. Although passing parameters to public flows is a straightforward process, it is crucial to follow the best practices to keep it secure. Otherwise, since the flow is public, you may end up exposing your entire database.

Public Screen Flow Example

Let's say that we want to build a flow that the customer can use to track the status of their support ticket (case). In order to do so, we should pass a parameter so that the flow can get that specific case record.

Customer can see the case details on the left side. Additionally, they can see the customer details on the right side.

Although it may look like a good solution at first, there are a few bad practices to avoid.

First of all, you shouldn't display any personal information. At the end, this is a public screen flow and the customer will have the link. Therefore, they can change the URL parameters. Secondly, the flow gets the case record according to the case number that we are passing from the URL. Therefore, it is very easy for the customer to guess another case's number.

See what happens when we change the case number from the URL. Another customer's details are exposed!

Let's remove the customer details from the flow, so that the flow will just display the case details. In this situation, you may think that it isn't a big deal if we expose another case's details to the customer. At the end, there is no personal information, right? Well, that's not always correct.

The customer can see all the field values from the developer tools, including all the personal information like phone number, email, address, etc. This is because we made the record variable available as output, which is not a good practice here.

As you can see, there are many security aspects to consider. Here are some best practices to enhance the security of your public screen flows.

Best Practices - Don'ts

• Don’t display sensitive data: Unless it is really necessary, and most of the time it isn't, don't display any sensitive or personal data.
• Don't pass any personal information as a parameter: Do not pass any personal information like email address, phone number, or ID number as a URL parameter. If you do so, anyone can easily change the parameters. On the other hand, it also means that you are already exposing personal data.
• Don't pass any easy to guess/change parameters: You should never pass easy to guess/change parameters. As you can see from the previous example, customer can easily change the case number and access another record. Therefore, avoid passing easy to guess parameters like auto numbers.
• Don’t mark variables available as output: When you mark variables available as output, one can easily access those variables using the developer tools. Therefore, unless it is necessary, do not mark variables available as output.
• Don’t store all record fields: In some situations, you may need to mark record variables available as output. For instance, if you are calling a subflow and expecting a record variable as an output, you must mark it available as output. In those situations, do not store all the fields, store the fields that you need.

• Be careful when passing record IDs: Passing record ID as a URL parameter may sound like a good practice. Record IDs are unique and 18 characters long, so they are hard to guess. However, when you have thousands of records, it becomes easier to change the ID and access another record. For instance, look at these IDs. They all look similar.

Best Practices - Dos

• Pass more than one parameter: Passing the record ID itself is not enough. Instead, you can pass multiple parameters and get the record accordingly. For example, pass both the case number and case ID. Here you can see an example.
• Hash record IDs: It is possible to use an Apex action to hash record IDs. Using the SHA256 algorithm, this action generates an impossible to guess 64 characters long key. Moreover, unlike record IDs, it doesn't follow any pattern.
• Send OTP: For critical flows that display sensitive data, you can generate 5 or 6 characters long key. Then, send this key to the customer via email and ask them to enter the code that they received. Read this post to learn how to send one time password to the users.

Summary

Even though passing parameters to public flows is straightforward, it's crucial to consider the security aspects and follow the best practices. Otherwise, there's a risk of inadvertently exposing your entire database.