Session based permissions for Salesforce1

Updated on Dec 9th 2017

While this trick may work for majority of use cases, I wanted to highlight certain caveats that you may want to consider. This is based on issues reported by others who tried this approach

1) Since access is removed to objects in mobile, obviously those objects/fields won’t be accessible in other places as well.. for e.g reports

2) You can’t apply login flows to API logins or when sessions are passed to the UI through frontdoor.jsp from a non-UI login process as explained here. So, this approach may not work for you if your are using canvas apps. You may have to plan for other workarounds in that case.


Recently a colleague of mine asked if it is possible to disable certain actions in Salesforce1 but allow them in desktop. Precisely, he wanted to know if he can allow users to create/edit/delete cases on desktop but prevent it using Salesforce1. Reason being, the case object has some custom visualforce pages that don’t render well on Salesforce1. Although my first response (and probably the right answer) is for him to fix the visualforce page to be responsive (using Lightning design system + components), I realized this could be a valid request for other use cases. For e.g., you may have an highly sensitive object that you want users only accessing on desktop while being on VPN and prevent access to it through other apps like Salesforce1. Granted you can just make the visualforce page not ‘Available for Salesforce1’ but that doesn’t prevent the user from using the standard actions. In this blog, I will explain how we can solve this requirement using ‘Session based permission sets’.

Solution

Session based permission sets available from Summer ’16 is a great way to assign certain permissions to the user based on session properties. For e.g., if the user is in an allowed IP range or if they are using certain types of apps etc. We will use this capability along with Login Flow to solve our requirement. Ready?

Step 1: From the user’s profile, remove Create, Edit and Delete permissions from case object

Step 2: Create a session based permission set. Make sure to check ‘Session Activation Required’

Step 3: In the permission set created above, allow Create, Edit and Delete on case object. Also make sure you assign the required record types

Step 4: Assign this permission set to your users

Step 5: Create a Visual workflow (Setup->Flows)

Step 6: Create a Formula resource called ‘IsSalesforce1’ of type Boolean as shown below. The formula to be use is IF({!$User.UIThemeDisplayed}=”Theme4t”,true,false)

Step 7: Create a constant named ‘Create_Edit_Cases’ as below. In the value of the constant provide the API name of the permission set that you created in step 2

Step 8: Drag a Decision element from the pallet and create an outcome called ‘Call is from Salesforce1’ as shown below

Step 9: Drag ‘Deactivate Session-Based Permission Set’ element from the panel and assign the ‘Create_Edit_Cases’ constant created in Step 7

Step 10: Connect the ‘Decision’ element to the element created in Step 9. Make sure you choose ‘Call is from Salesforce1’ outcome

Step 11: Drag ‘Activate Session-Based Permission Set’ element from the pallet and assign the ‘Create_Edit_Cases’ constant that you created in step 7

Step 12: Connect the ‘Decision’ element to the element created in Step 11. Make sure you choose ‘Default Outcome’ as the outcome. Also, make sure to mark the ‘Decision’ step as the start step. Your final setup show look like below

Step 13: Save and Activate the flow

Step 14: Go to Setup->Login Flows and create a new login flow as below. For e.g., name it ‘Session Level Policies’. Make sure you assign this login flow to the right profile(s)

That is it! Now, go ahead and test this out. When you login using full desktop (Lightning experience or classic), you should still be able to create/edit/delete cases. But, when you login using Salesforce1, you will only be able to view the cases. If the user you are testing this with is already logged on to Salesforce1, make sure to log off and log in again so that the changes can take effect.

Summary

Sessions based permission sets give you a lot of power to fine tune user access based on various session parameters. Although, in this specific use case my recommendation would have been to fix the VF pages to be responsive, so that you are not taking away key functionality from the user, I wanted to share this approach for other ‘legitimate’ use cases where you want to prevent certain access on certain UIs. In other words, you could even reward your users to use Salesforce1 more often by only allowing certain features in Salesforce1 and not on desktop. How about that!


Now, the fine print.. At the time of writing this blog, I am employed with Salesforce as an Architect. However, any code samples and declarative approach provided here are purely for experimental purposes and comes with no warranty or support. Matter of fact, all opinions and approach provided in this blog are purely my own and has nothing to do with my employer. It is assumed that you have the right Salesforce configuration and coding skills and will use the ideas presented here as you see fit, in your landscape. The primary purpose of this article is just to share the knowledge and my own experience. Nothing more, nothing less. Use this approach at your own risk

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.