Flow is the strongest automation tool of Salesforce. You can build flows to let the users perform actions, even the actions they do not have permissions. However, once you publish a way to use the flow, (for example, an action button, placing the flow on a Lightning Page, etc.) then all the users that have access to it can use it. You can read this post to learn more about the ways to launch a flow. Let's say that you created an action button that launches a screen flow and put it on the page layout of the object. Then all the users that use this page layout will be able to see the action button and use it. In some cases, you might want to give permissions to specific users or profiles. Hierarchy custom settings can be used for this purpose. It means that even though other users will be able to see the action button/flow, they won't be able to use it.
Let's say that we have a screen flow that lets the users change the case owner. We created an action button and it is available on the page layout. However, we want only specific users to use it. It is not possible to hide the action button for the rest of the users but it is possible to display an error message for them.
Creating Custom Settings
As mentioned above, it is possible to use custom settings to give permissions to specific users and profiles. There are two types of custom settings in Salesforce: Hierarchy and List. In this use case, hierarchy custom settings fits to the requirement. Hierarchy custom settings use a built-in hierarchical logic so that you can personalize settings for specific profiles and users. You can define default settings for the organization and add specific users or profiles to override it. Profile settings override default organization settings and user settings override them all. Read this article to learn more about custom settings.
Find Custom Settings in setup in order to create a hierarchy custom setting.
Create a new hierarchy custom setting called "Case Change Owner Settings".
Click on Manage and then click on New button to add a specific user or profile.
As you can see in the picture below, you can search for a profile or a user in order to add to the custom settings.
Add all the users and profiles that you want to give permission for this flow.
In this use case, we just need a list of users and profiles. If you have a more complex logic, you can create fields in the custom settings to give more detailed permissions.
Checking User Permissions in the Flow
After creating the hierarchy custom settings, you have to use it in your flow. Let's say that this is your existing flow. It gets the case record, checks some criteria, displays some information, and then changes the owner.
However, the issue is that anyone can run this flow (if they have flow permissions in general). Let's add a check to see if the current user has permissions to run this specific flow.
1. Add a Get Record element to find the "Case Change Owner Settings" record according to the current user's Id or ProfileId. As mentioned before, custom settings can contain users and profiles, this is the reason why you have to check both of them.
2. Add a Decision element to check the result of the Get Record that you performed. If a record exists, then it means that the user has permissions.
3. Add a new Screen and display an error message. It is not a must, but it is better to display something to the user. So that they will understand what is happening.
Put all of these 3 additions to the beginning of the flow. So that it won't continue if the current user doesn't have permissions.
At the end, the flow should look like this.
Let's add the user to the custom settings and run the flow. As you can see, flow runs successfully.
Now, let's remove the user from the custom settings and see what happens. As you can see, the same user cannot use the flow.
Using a Custom Object Instead of Custom Settings
If you use custom settings for this requirement, an admin needs to maintain the list. Since it is defined in the setup, not all the users have access to it. In order to give the responsibility to non-admin users, you can use a custom object instead of custom settings. This way, they can have a tab for the object and maintain the list from the custom object. On the other hand, they can use tools like Data Loader to maintain the list. If you decide to do this, then pay attention to give permission to this object only to the users that will maintain the list. Other users and profiles shouldn't even see the object. If you run your flow in the system context, even if the user cannot see the object and the records, flow will run successfully.
Create a custom object and a lookup field for the user that you want to give permission. It is not possible to create a lookup field to profile but you can use a text field to store its Id or name. Optionally, if you are planning to use the same object for multiple flows, create a text field that stores the name of the flow. This way, you won't need to create a different object for each flow. You can also add start and end dates (or date/time) to give permissions for a limited time.
After creating the object and the records, perform a get for this object instead of custom settings. If you added the optional fields for the flow name and start/end dates (or date/time), you can add them to your get conditions.
Don't forget to change the Decision conditions according to the result of this new get that you performed. As it is mentioned above, run the flow in the system context so that it will successfully find the permissions from the custom object.
I am not sure but is this solution can also using dynamic action with custom permission in component visibility criteria?
You can use this for visibility of screen components or even skipping some steps in the flow.