Funny how you hope you know stuff, and, then, you discover something very basic that’s not working the way you’d think it would.
That’s my life, though.
I was having a hard time trying to figure out why a user with Sales Manager permissions can use a link to access a Flow I created. And not only to access it, but, also, to modify it and to save those changes.
No, that flow would not show up under flows:
However, if that user knew what the link is to the flow, they would be able to open the flow and edit it:
A little weird you’d think? Well…
My Sales Manager user account had only “Sales Manager” role assigned to it. So, I tried something else – I went to the environment to have a look at the workflows under that user account, and, to my surprise, I could actually activate and deactivate pretty much any of the classic workflows:
Turned out it’s all about how the role is set up:
Sales Manager role allows “write” access to the process (which is also “workflows”, and which is also “Flows”) records in the user’s business unit.
In this environment, there is only one business unit, so, even though the workflows and flows are created by system admin and/or deployed through the solutions, a lot of non-admin users might end up having access to those flows just because they have permissions out-of-the-box.
How do you mitigate this?
There seem to be a few options:
- Tweak your security roles so that BU-write on the workflows is not allowed. For example, here is how SalesPerson role is dealing with this:
- Although, maybe your users want to have access to each other’s workflows/flows, in which case you might create a child BU and move all non-admin/non-customizer users into that BU instead. once they are there, they can still share workflows in their BU, but they wan’t be able to update system workflows anymore
Either of that would work for both Flows and Workflows.