The Future of User Management

Customize Application is a hot mess  

It's not fully documented, complicated and grants too many permissions. 

As Trailblazers we have a opportunity to make things better by upvoting; 

1. Customize Application should be fully documented
2. Split the Customize Application Permission
3. Interactive Permissions Dictionary

Read; The Complete Guide to ‘Customize Application’ for Salesforce Admins on Salesforce Ben 

#AwesomeAdmins #Agentforce #CRM Configuration #Flow #New Releases #Security #Salesforce Developer #Reports & Dashboards #Analytics #Trailblazer

@* Release Readiness Trailblazers * @* Salesforce Administrators * @Trailblazer Community Cove @* Salesforce Platform * @* Customer Success * @* Salesforce Developers * @Architect Trailblazers @Agentblazer Community Group

Does anyone have a link to how I can setup Nested Permissions Set Groups. 

Example:  Customer Service has 3 Tiers of Permissions.  

Tier 1 - Perm Set Group 1

Tier 2 - Perm Set Group 1 plus additional Perm Sets Creates Perm Set Group 2

Tier 3 - Perm Set Group 2 (Includes Perm Set Group 1) plus additional Perms Sets Creates Perm Set Group 3

Does anyone know if we can do this that if i add something on Perm Set Group 1 that it will add to the other 2 based on the nesting?

Thanks

Like many Admins, I’m attempting to move our user access (particularly Object/Field access) to be on Permission Sets instead of Profiles.

I am struggling with how to handle what I consider default Users with default Profiles created by Salesforce. I’m talking about users such as:  Integration User, Security User, Insights Integration, etc. 

My understanding is that these users should have Field-Level Security set to visible for all fields, but these users by default only have a Profile. Are others creating a special Permission Set for these users in order to easily give access when fields are created? Or do you just continue to assign to Profiles when creating new fields, then add to Permission Sets for your “regular” users later?

Frankly, I don’t have a good understanding of the function of these users, so I’m unsure of what access I need to be sure to grant as our org evolves. Any insight/advice would be appreciated. 

Profile optimisation work:  

I’m trying to understand the Administrative permission on profile level

 does anyone have experience with when this is actually required?  

 In our org, when users have Read/Create/Edit access on an object, they can edit inactive-owned records even if the

permission is disabled. Enabling or disabling this permission doesn’t appear to affect UI behaviour in this scenario.  

Set Audit Fields upon Record Creation’ and ‘Update Records with Inactive Owners’ user permissions.  

If anyone has experience or suggestions around this permission, that would be very helpful.  

Thanks

I have a new client with a crazy mess of permission sets and profiles.  It looks like some other consultant converted all their previous profiles straight into permission sets and we now have about 150 permission sets named after various roles in the company, with no documentation of course.  Any suggestions on how to start sorting this out? 

1. Sys Admins - do people generally have a single permission set for Admins that has R/W access to all fields/objects rather than relying on the profile?  Now that the field creation flow shows permission sets, we have lots of fields that are not available to system admins as it was not added to the admin profile.
2. Role based vs functionality or object based - any thoughts on having perm sets around each object (view only vs standard user edit vs special edit scenarios) or by functionality (quotes and opps together for a 'Quoting' permission, other objects grouped for 'Account Mgmt' and 'Customer Service' etc)?
3. Any recommended tools you have used to document or discover what is in each of the existing permission sets to evaluate if we keep them, or perhaps we just start fresh and eventually retire all the existing perm sets?

Thanks for any advice or experience you can share 

Hi @Cheryl Feldman

, 

The Winter '26 Release Notes indicate the 

will be collapsible and available when working in the Object Manager.  However, my Preview org does not represent this desirable enhancement.  I don't see any instructions to indicate it is a feature that needs to be enabled.   

I also don't see this feature on the

list. 

Can you please provide some clarity on this? 

Thanks so much!

Hello Team 

I am in the midst of this sort of pivot from profiles to a "minimal" profile + n modular permissionsets setup. 

Conceptually I like the idea - all good with that. I know the official guidance tends to suggest people down this path, and there are a few articles and things around giving pointers. 

I know we have recently that User Management feature that lets us replace the profile selection with the permissionsets selection when creating a new field. That is a good help. 

But in my journey towards this overarching goal, I have found a few other places where the platform will still automatically surface the profile UI instead of permission sets, which makes it very difficult to keep aligned with the overarching goal. The two main examples I have found are these, but there are other places where the platform will automatically set object-level perms on profiles that I have seen too.

1. Installed Manage packages - https://ideas.salesforce.com/s/idea/a0BHp000016L5E9MAK/install-managed-package-for-permission-sets-not-profiles
2. Enabling FieldService setting in the org - will automatically grant a random set of workorder-related object-level perms on profiles

Are these planned to be resolved at some point? I find it strange I find little reference to these things online. Is the reality that most customers are not trying to do this?

Hello All, I am trying to deploy user access policies from my sandbox to a repository with gearset. The deployment fails validation with reason: You cannot deploy User Access Policy as active without at least 1 action and 1 filter. I have compared my UAP metadata with the sample provided by Salesforce in the https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_useraccesspolicy.htm?q=user+access  and it is exactly same. Is there anything I am missing.

We wanted to start using User Access Policies but during release testing we noticed that UAPs are deactivated by deployment even when no changes were done. 

We are deploying complete metadata every time so UAP are always included in the deployment. 

Scenario:

• deploy UAP
• activate
• deploy UAP without any change

Result:

• UAP is inactive/Design status

Are we missing something?