Skip to main content
Tom Bassett (Senior Solution Architect at Vera Solutions) Forum Ambassador
3 comments
  1. Apr 9, 2:35 PM

    I too 100% agree on this. Not thought out at all by Salesforce.

0/9000

Honest question for fellow Salesforce Admins…

Does this request sound familiar?

“Can you give this new user the exact same access as that other user?” 

 

And suddenly you’re:

  • Opening multiple permission sets
  • Checking permission set groups
  • Clicking through assignments
  • Hoping nothing gets missed
  • Double-checking everything

After living this workflow more times than I’d like to admit, I built(vibe coded) a small UI tool to simplify it.

It allows you to:

  • Select a source user
  • Select a target user
  • Copy permission sets
  • Copy permission set groups
  • Optionally copy the profile
  • Optionally remove existing assignments

Nothing fancy — just something vibe coded to remove a very common admin headache.

 

It’s open source, and I’d genuinely appreciate feedback from real-world usage:

Github

 

 

If you have any questions or would like to contribute, please reach out to me on

LinkedIn 

3 comments
0/9000

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

9 answers
  1. Andrew Russo (BACA Systems) Forum Ambassador
    May 18, 2023, 2:21 PM

    this is not possible. @The Future of User Management

0/9000

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. 

 

@The Future of User Management

4 answers
  1. Feb 7, 10:06 PM

    Hi @Marie Garmoe

     

     

    Best practice is to keep Profiles minimal and give all object/field access via dedicated Permission Sets for Integration/System users. When new fields are created, update those Permission Sets—not Profiles.

0/9000

Profile optimisation work:  

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

Update Records with Inactive Owners permission,

 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

Update Records with Inactive Owners

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

Note:  I’ve disabled the UI setting

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

3 comments
0/9000

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 

@User Access & Permissions Assistant @The Future of User Management @Architect Trailblazers

10 answers
  1. Feb 2, 8:41 PM

    Thanks everyone for chiming in, this is a great discussion.  @Mike Megliola I have used PermComparator before and it's pretty good at highlighting differences but still doesn't show all the nuances of what you can have on a profile (record types, page assignments etc).  I'm going to check out Jetstream and I think I will likely ignore most of what the client has today and start fresh.  The existing permission sets are mostly just profiles that were auto converted into perm sets and have a lot of conflicting information, like FLS on objects that they don't have CRUD for etc.  

0/9000

Hi @Cheryl Feldman

 

The Winter '26 Release Notes indicate the 

Setup sidebar

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

Release Note Changes

list. 

 

Can you please provide some clarity on this? 

 

Thanks so much!

1 answer
  1. Dec 4, 2025, 12:46 PM

    Yeah, some preview orgs don’t always get the full UI changes right away, even if they’re in the release notes. Could be that the collapsible sidebar is part of a phased rollout or tied to a specific user perm in Setup. I’d double‑check in Setup > User Interface for any new toggle, and maybe log a case if it’s still missing so they can confirm if your pod has it yet.

0/9000

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?

1 answer
  1. Dec 4, 2025, 9:42 AM

    Yeah, you’re running into some of the legacy gaps where profiles are still baked into certain setup flows. Salesforce’s long-term direction is definitely “minimum profiles + perms sets,” but not every feature or managed package install respects that yet. Best thing is to upvote and follow those IdeaExchange posts, and log cases so Product hears it’s blocking you — that’s usually what drives those changes.

0/9000

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.

18 answers
0/9000

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?

4 answers
0/9000