Have you ever come across a permission limitation that you couldn’t solve using a Permission Set? Every once and a while we get requirements that can test the limits of what we can technically do with Salesforce. It might be a Field Level Security issue, or it might be a License limitation. Before Process Builder was around, if you wanted to get by some sort of limitation like this, you had to write code. Not anymore! Process Builder runs in the context of the System.
So… when Visual Flow is that when its autolaunched by Process Builder, it too will run in the context of the System and not the Running User. This means any Field Level Security, Profiles, Roles, or License type can essentially be ignored. Think of an Autolaunched Flow as temporarily giving somebody temporary Admin access. Where this can get interesting is when we start to think of all of the different ways we might use this!
Get creative! You can do all sorts of cool things to bypass Licenses and Security issues by using Autolaunched Flows. Here are a two examples to get you thinking:
Site.com Guest User Access
In this scenario we want to send an email to our clients to propose that we close a Case, and in that email present them with a Yes and No button. If they click the button you want the Case to properly react. That means we need to have that button click send them to a specific URL (associated to our Site.com) with a unique parameter that matches to our Case. The problem is we are unable to have an unauthenticated User edit a Case. We can give the Site.com Guest User access to Create on a Custom Object, and have that Custom Object then trigger a Process Builder to run and find and edit the Case. There are some obvious security issues, but they can be solved by building your parameter and Flow correctly.
Add and Remove Permission Sets and Public Groups
We want our Marketing Manager to be able to add and remove people to a Permission Set and/or Public Group. We can create a Checkbox or Picklist on the User Object, and have an edit to that field trigger a Process Builder to launch our Flow where we either add or remove them to the Permission Set and/or Public Group. Access to this field can be then controlled by a Permission Set or by Profile. With this, we can essentially delegate any Admin function to any User without given them Admin privileges!