User Management Settings
User Management Settings is a Setup page in Salesforce where an administrator turns org-wide user administration features on or off.
Definition
User Management Settings is a Setup page in Salesforce where an administrator turns org-wide user administration features on or off. It is the single place to enable things like enhanced list views for users, profiles, and roles, contactless users, user self-deactivation, the email domain allowlist, user access policies, and the ability to scramble a user's personal data.
The page does not manage individual people. It controls which user-management capabilities the whole org gets. You reach it under Setup, in the Manage Users and Data Access section. Each toggle is a switch that changes how admins and external users interact with user records across the org.
What the toggles actually control
Where it lives and what it is for
You find User Management Settings under Setup, in the Manage Users and Data Access area, near User Management itself. The page is a flat list of checkboxes. Each one enables a feature that affects how user records behave for the entire org, not for one person. Think of it as the control panel for user administration. The individual User object holds names, emails, profiles, and roles. This page decides which tools surround that object. For example, it decides whether admins get the enhanced list views that let them edit many user rows inline, whether external users can switch off their own accounts, and whether you can permanently anonymize someone's personal data. Because the settings are org-wide, a single checkbox can change the daily experience for every admin and, in some cases, every external user. That is why the page sits in Setup behind admin permissions. Most options are off by default, so nothing changes until you deliberately switch something on. Review the list once during org setup, then revisit it when your security or privacy policies change.
Enhanced list views for users, profiles, and roles
Several toggles on this page turn on enhanced list views. There are separate switches for Enhanced User List Views, Enhanced Profile List Views, Enhanced Role List Views, Enhanced Permission Set List Views, and Enhanced Public Group Assignment. Each one upgrades the matching Setup list from a plain read-only table into an interactive grid. The practical win is inline editing. With Enhanced Profile List Views on, an admin can select rows, change a value, and save without opening each record. The same idea applies to users and roles. For an org with hundreds of users, this turns a slow click-through into a quick bulk edit. You can also customize columns, sort, and filter the list more freely. There is also Enable the Enhanced Profile User Interface, which is a different thing. It changes the profile detail page itself into a tabbed, searchable layout instead of one long page. Admins who manage permissions often prefer it. These list-view and UI toggles carry no privacy risk; they are pure convenience and a good first thing to switch on in a new org.
Scrambling user data for privacy
The Let Users Scramble Their User Data option is the one that needs the most care. Turning it on enables the System.UserManagement.obfuscateUser Apex method. That method permanently anonymizes a user's personal data so the person can no longer be recognized in the org. This exists for privacy laws and data-subject requests. When someone has the right to be forgotten, scrambling lets you honor that without deleting the user record and breaking its many relationships. The catch is that the action cannot be undone. Salesforce is explicit that once you invoke the method, the data becomes anonymous and you can never recover it. You call obfuscateUser from code: a trigger, a flow, an invocable action, or the Developer Console. It does not fire an email-change notification, so plan your own communication if one is needed. The setting requires Enterprise, Performance, Unlimited, or Developer Edition, and the running user needs Customize Application. Treat this like a one-way door. Confirm the request, log who approved it, and test in a sandbox before you ever run it in production.
User self-deactivation for external users
Enable User Self-Deactivation lets external Experience Cloud site and Chatter users switch off their own accounts. It does not apply to internal employee users. The result is identical to an admin-initiated deactivation: the person loses login access, but the user record stays in the org for history and ownership reasons. Deactivation is not deletion. The record remains, which is why any records the user owned still point at them. Before you enable this, decide how you will handle orphaned ownership. If a self-deactivating community user owned cases or custom records, you may want a flow or a scheduled process to reassign them. Switching the setting on is only half the job. You also have to give users a way to trigger it. For Aura-based Experience Cloud sites, the Customizable User Settings component exposes the option. For LWR or Visualforce-based sites, you build a custom flow or page that calls the deactivation. This is convenient for users who want to leave on their own, and it cuts the admin queue, but only enable it once the reassignment plan is in place.
Contactless users, the email allowlist, and access policies
A few more toggles shape how user records are created and governed. Enable Contactless Users lets you create users who are not tied to a Contact record, which reduces overhead for some external scenarios. It is useful when you need many lightweight identities without the full account-and-contact structure behind each one. Enable the Email Domain Allowlist (sometimes shown as the email domain allowlist) restricts which email domains are permitted in user records. With it on, you can stop user emails from being set to domains outside an approved list. That guards against typos and against provisioning accounts on the wrong domain. Enable User Access Policies turns on a framework that automates assigning users to permission sets, permission set groups, package licenses, and more based on criteria you define. Instead of hand-assigning access to each new hire, a policy grants it automatically when the user matches the rule. There is also Enable User Field History Tracking, a beta option that audits changes to user data so you can see who changed a field and when. Each of these touches provisioning, security, or audit, so align them with the policies your security team owns.
Profile and permission guardrails
The page also carries options that tighten how profiles and permissions are managed. Limit Profile Details to Required Users restricts profile visibility so users see only their own profile rather than every profile in the org. That is a small privacy and tidiness win in larger orgs. Restrict Permissions Cloning in Profiles makes sure that when an admin clones a profile, only permissions the admin can actually access get enabled on the copy. It prevents a clone from silently carrying forward access the admin should not be granting. Enable Field-Level Security for Permission Sets during Field Creation changes where new-field security is set, pushing it onto permission sets instead of profiles, which fits the modern move away from profile-based permissions. None of these change a single user record on their own. They change the rules of the road for whoever administers users next. Because they are org-wide and quiet, document why each one is on. A future admin staring at the page should be able to tell which toggles reflect a deliberate security decision and which are just defaults nobody touched.
How to configure User Management Settings
User Management Settings is a Setup page of independent toggles. You do not create a record here. You enable the org-wide user features your policies call for. Open the page, switch on what you need, and pair risky options with a documented plan.
- Open the page
From Setup, in the Quick Find box, search for User Management Settings and select it. It sits in the Manage Users and Data Access section. You need an admin profile or the equivalent setup permissions to see it.
- Turn on the convenience features first
Enable the enhanced list views you want, such as Enhanced User List Views and Enhanced Profile List Views, plus the Enhanced Profile User Interface if your team prefers it. These carry no privacy risk and speed up daily admin work.
- Enable governed features with a policy behind them
For options like Enable User Self-Deactivation, the Email Domain Allowlist, User Access Policies, or Let Users Scramble Their User Data, confirm the matching policy exists first. Save the page, then build any supporting flow or component the feature needs.
- Document and test
Record why each toggle is on and who approved it. Test self-deactivation and any obfuscateUser call in a sandbox before production, since scrambling user data cannot be undone.
Upgrade Setup lists into interactive grids that support inline editing, filtering, and column customization for faster bulk admin.
Enables the System.UserManagement.obfuscateUser Apex method to permanently anonymize a user's personal data. The action is irreversible.
Lets external Experience Cloud and Chatter users deactivate their own accounts, with the same effect as admin deactivation.
Restricts which email domains are allowed in user records so accounts cannot be provisioned on unapproved domains.
Automates assigning users to permission sets, permission set groups, and licenses based on criteria you define.
- Scrambling with obfuscateUser is permanent. Once invoked, the user's data is anonymous and can never be recovered, so test in a sandbox and require sign-off.
- Self-deactivation only covers external Experience Cloud and Chatter users, not internal employees, and it leaves the user record (and its owned records) in place.
- Enabling self-deactivation is not enough on its own. You still have to expose it through the Customizable User Settings component or a custom flow for users to actually trigger it.
- Most toggles are org-wide and quiet, so an undocumented change is hard to spot later. Note why each enabled option is on.
Trust & references
Cross-checked against the following references.
- User Management SettingsSalesforce
- Let Users Scramble Their User DataSalesforce
Straight from the source - Salesforce's reference material on User Management Settings.
- User Management SettingsSalesforce
- Enable User Self-DeactivationSalesforce
Hands-on resources to go deeper on User Management Settings.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. In which area of Salesforce would you typically find User Management Settings?
Q2. Can a Salesforce admin configure User Management Settings without writing code?
Q3. What is the primary benefit of User Management Settings for Salesforce administrators?
Discussion
Loading discussion…