Salesforce Permission Sets in The Welkin Suite
Permissions sets in Salesforce is a great tool - to keep profiles clean, and their number low, to distribute permissions differentiation with your AppExchange packages, and for lots of other purposes. However, due to the power they provide, they are as well very complex tool to work with. This applies to all the stages of Permission Sets lifecycle - starting from the creation, and up to assigning and revoking, especially in old or big environments with a complex security model.
Salesforce has done a great job building a clear and useful interface for permission sets management, but another interesting point is that they involve administrators, declarative developers, and those who write the code - and each of these roles usually requires separate functionality and, ideally, different interface to access them. As you might know from our Spring release announcement, we are going to extend The Welkin Suite experience for Permission Sets in addition to the existing functionality, so let's go through some of the ideas that we have, and see at a high-level, what is going to be implemented in our upcoming releases.
You may be thinking "The Welkin Suite is an "Integrated Development Environment", so what for are you guys adding the tools for administrative tasks?". Let me cast some light on what we'd ultimately like to achieve - a unified tool that will be familiar to everyone, who participates in Salesforce development and maintenance processes. Clearly, the more difference in tools and processes Salesforce developers and administrators have in their regular work, the harder it will be for all of us to find common ground, and to build great user experience - which is our ultimate goal, right?
Managing Permission Sets assignments
The first and the most obvious area for improvements is assignments management - you can easily assign a permission set to different users using the standard Salesforce UI, or you can assign multiple permission sets to one user. However, this is only suitable and usable in late-administrative tasks, when you add a new user or permission set, and need to adjust the existing permissions model. In cases when you need to globally reconfigure the permissions model, or assign multiple permission sets to multiple users, you need to go through different pages and do everything step-by-step. Imagine (or remember?) installing an AppExchange package with 15 different permission sets in your organization with 170 users - configure the assignments will turn into a nightmare!
That is why we believe that the approach that we have used for our FLS management is much more useful and intuitive, and it will help you save some time that you can spend on more interesting tasks. Below is the FLS management UI with the Permission Sets-related comments.
Permission Sets assignments are like tweets on Twitter - if you don't filter them out, you'll drown in them with no results. But if you have different options to filter the information - you will quickly build the way to that needle in the haystack that you were looking for. Want to filter among users according to their license, profile, or other assigned permission sets? Sure, not a problem. Would prefer to filter permission sets by the required license, custom permission, or any other permission that they grant (for example, see only those permission sets, which grant write access to the field X, Apex class Y ,and Visualforce page Z at the same time)? Again, not an issue at all. Well, maybe not all of these filtering options will be implemented at the very beginning, but they will be done for sure. By the way, your opinion on which filtering options you'd like to see first will definitely impact our decision - so share it in the comments!
Permission Sets editing
Moving from the administrative to more of the development tasks, we will for sure start with the editing functionality. And thinking about AppExchange developers, who are usually operating with lots of permission sets - we will also cover batch editing (Salesforce's best practices applied - everything should be bulkified ). Considering the heterogeneous nature of different permissions, which can be configured in Permission Sets - it will be a very interesting challenge for us to build a proper UI, which will improve your productivity, and won't add too much informational noise on the screen.
This is how we see the future UI of the Permission Sets editor right now. On the left, you will see the categories with all sub-items (if any), while on the right you will see only the table-like view of options in the selected sub-item. This way, you will always work with the same data types, and from our viewpoint, the UI looks quite intuitive. There will be some nice and cool things like the one shown on this mock-up - showing the dependencies in System Permissions in much more friendly way, so you won't need to scroll back and forth to read the descriptions of the required permissions. And of course, such approach to creating the UI will allow us to easily implement bulk editing of permissions sets (or at least, you will be able to see the configuration for one permission set, and modify another one at the same time).
Permission Sets comparison
Another common task is to compare multiple permission sets to find out some differences - or something they have in common. This can be crucial in many cases, however, there is no such functionality in the standard Salesforce UI. That is why we keep this on our radar, but we are not yet sure if this will be implemented as a part of our Spring Release.
Don't agree? Have other ideas? Great!
These are some of our plans, which we have built on top of our own Salesforce experience, as well as the suggestions we've heard from others on social media and during different events. If you have your own vision of what and how should be implemented in The Welkin Suite related to the Permission Sets - let us know in comments, and I will be happy to discuss your ideas, and adjust our plans and vision if needed!