The Future of User Management

This post is a follow-up to a packed session we held at #DF22 called “The Future of User Management.” We want to provide a summary of the session for those of you who weren’t able to get into the session due to room capacity or weren’t able to attend Dreamforce in person.

Our session at Dreamforce came about because we, as product managers at Salesforce, wanted to let all Salesforce Admins know that we hear you. Over the last several months, we’ve met with and heard from hundreds of #AwesomeAdmins during events, in individual feedback sessions, on Twitter, on the Trailblazer Community, and on the IdeaExchange.

What’s become clear to us is that user management is hard. It’s hard because we’ve consistently told you to use permission sets over profiles, yet it takes over a dozen clicks to see what’s actually in the permission set. We also learned that you’re spending up to 50% of your time in some cases troubleshooting user access. And because there are so many ways a user can get access to a record or be able to do something, it can take you potentially hours to identify why someone has or does not have access. The last theme we heard is that we make you make some really difficult decisions around granting access. Do you give your end user Modify All Data, do you not allow them to do what they want in the platform, or do you need to take on this work?

In this blog post, we share how we plan to address these challenges.

Note: Everything we discuss in this blog post is forward-looking and we’re not sharing any dates at this time.

We’re asking you, #AwesomeAdmins, to come on a journey with us. Give us your feedback. Do we understand your challenges? Are the solutions we’re proposing helpful, or is something missing? Let’s dive in. At the end of this post, we’ll have a link to a group on the Trailblazer Community where you can give us your feedback.

Challenge: Using permission sets and permission set groups is too complex

Over the last few years, we’ve encouraged you to use permission sets and permission set groups over profiles to grant permissions to users. However, this has added time and complexity to your day because it’s a minimum of a dozen clicks to see what’s in a permission set. It takes many clicks to add a permission set to a permission set group, and if a permission set needs to be in many groups this becomes a highly frustrating experience. In addition, if a user has multiple permission sets and permission set groups assigned to them, it becomes increasingly hard to understand what this one user actually has access to. I think Patrick Stokes put it best at True to the Core: “This is a quality of life issue.” When you have to repeatedly do something that’s, well, annoying, it impacts you!

How we plan to fix this

We’re reimagining the look and feel of permission sets and permission set groups. We want to bring you an improved List View experience with the ability to select multiple permission sets and add them to a group, to be able to easily filter on the permission sets you want to see. We also want to make the overall UI of permission sets more seamless. To be able to easily tell what’s in a permission set and to change access in a permission set. Here are some examples of what we’re thinking.

Challenge: Admins spend too much time troubleshooting

The second thing we heard quite a bit from our customer and partner conversations was that you are spending so much time troubleshooting. At Dreamforce, I had a conversation with an #AwesomeAdmin who shared that he spent nearly six hours the week prior troubleshooting why a subset of his users lost access to records in a custom object. After hours of troubleshooting, he realized that another admin accidentally changed the organization-wide default from Public Read-Only to Private. I’ve heard hundreds of stories like this. And, as a former #AwesomeAdmin, I’ve stayed up late many times trying to figure out why a user could or could not do something.

How we plan to fix this

For this challenge, we believe the first feature we should deliver involves the ability to compare the access of two users. Our vision is to give you the ability to understand how a user has access to a specific record when another user does not. Below is a mock-up of how we think this should look. What else would you want to see here? Would a feature like this help with your troubleshooting?

Challenge: Admins are living in spreadsheets and other external databases to manage access

From the many conversations we’ve had, we’ve found that so many of you are maintaining these huge spreadsheets, databases, flows, or other documents to manage user access. These systems help remind you what a user needs to be entitled to or, in the flow’s case, help you automate, but that still requires a lot of maintenance on your part. I’ve seen admins using custom objects, custom metadata types, and all sorts of creative solutions, but what’s clear is that it’s a huge amount of maintenance no matter how you do this.

How we plan to fix it

In Winter ’23, we introduced a new feature in closed Beta called User Access Policies, which will allow you admins to define criteria about your users. These criteria can be entitlement-based (which profile they are in, which permission sets are assigned) or attribute-based (field on the user record).

From there, you can define actions to either grant or revoke access. If you want to see a demo of this feature, watch the Admin Release Readiness Live Preview on Salesforce+.

The goal of this feature is to get you out of your spreadsheets and make automation much easier. We still have three to four releases of work before this is Generally Available (GA). Below is a proposed revamped UI for the tool. What do you think about this? How would you use user access policies?

In addition, we’re thinking about another feature that complements User Access Policies: Recent User Access Changes that will show you what access was applied to whom and when through a User Access Policy. In the future, we would also show this on a user record so you can see what changed for a particular user. Here’s an example of what we’re thinking.

Challenge: Operating by the principle of least privilege is difficult

We’ve made it really hard for you to operate by the principle of least privilege due to what I call super permissions. As admins, we make you make some really tough decisions, such as giving your end users Customize Application to manage one small customization or deciding that you and your team have to take on that work.

If you have many of our products, there’s a possibility you’ll see up to 861 user permissions (app and system permissions), and this doesn’t include object and field-level permissions. That’s a lot for you to understand and manage! If we just broke up the super permissions, like Customize Application, it could create somewhere around 3,600 permissions! This would become a nightmare for you to manage—and we’re looking to make things easier for you, not harder.

How we plan to fix it

We’re contemplating creating a new construct where you can group metadata and assign that to a permission set. You could then give that permission set the Customize Application super permission, and the users assigned to that permission set would only be able to customize what’s in that grouping. What do you think? Would something like this help you?

Help us shape the future of user management in Salesforce!

If this is something you’re interested in, join our Future of User Management group on the Trailblazer Community where we’ll share our progress.

Acknowledgments

This Dreamforce session and this post would not have happened without our incredible UX Designers Anubha Dubey and Sanika Doolani. I would also like to thank my manager, Belinda Wong and my fellow Product Manager, Larry Tung for their insight and partnership.