---
title: "What profiles still uniquely control"
url: "https://trailassembly.com/what-profiles-still-control/"
topic: "Admin and Permissions"
published: "2026-09-10T08:30:00+00:00"
updated: "2026-10-06T13:52:04+00:00"
---

# What profiles still uniquely control

**Straight answer:** nine things, and page layout assignment is the one that keeps profiles in your org forever. Every user still has exactly one profile, and a permission set cannot assign a page layout, set a default record type, set a default app, restrict login hours, restrict login IP ranges, override password policies, override session timeout, run a login flow, or control data category group visibility. Everything else you were doing on profiles belongs in a permission set.

## The list, and how each one was confirmed

Salesforce publishes a profile-versus-permission-set table in Permissions and Access Settings, but it is not a complete inventory — it has no row for default app, password policies, or session settings. So the entries below are cross-checked against the Metadata API, which is the more reliable test: if the `PermissionSet` metadata type has no field for something and `Profile` does, no permission set can express it.

| Setting | Why it’s profile-only |
| --- | --- |
| Page layout assignment | Profile.layoutAssignments exists; PermissionSet has no equivalent field. The Help table shows Profiles only. |
| Default record type per object | ProfileRecordTypeVisibility has a default field; PermissionSetRecordTypeVisibility has only recordType and visible. |
| Default app | ProfileApplicationVisibility has a default field — “only one app per profile can be set to true”. PermissionSetApplicationVisibility has none. |
| Login hours | Profile.loginHours; no permission set counterpart. |
| Login IP ranges | Profile.loginIpRanges; no permission set counterpart. |
| Password policies | Separate metadata type ProfilePasswordPolicy with a required profile field. There is no PermissionSetPasswordPolicy. |
| Session settings and timeout | Separate metadata type ProfileSessionSetting (API 40.0 and later), required profile field. |
| Login flows | Profile.loginFlows; no permission set counterpart. |
| Data category group visibility | Profile.categoryGroupVisibilities; no permission set counterpart. |

Two further profile-only entries exist but rarely drive design decisions. `Profile.profileActionOverrides` controls Lightning Home page action overrides. And a profile carries a user license — the Metadata API states that every user must have exactly one user license, which is why you cannot move a Platform user onto a Salesforce-licence profile without changing their licence.

Things I deliberately left off: desktop client access and the relationship between profile login IP ranges and org-wide Network Access trusted ranges. Both are widely repeated, and neither is something I could confirm against a documentation page that actually rendered. If you need the trusted-IP-range distinction, check it in your own org rather than taking anyone’s word for it.

## Record types are the item most people get backwards

[Permission sets](https://trailassembly.com/permission-sets-after-cancellation/) *can* assign [record types](https://trailassembly.com/record-types/). This is the single most common error in advice on this topic, and it sends people back to profiles for no reason.

What a permission set cannot do is make a record type the *default*. Configure Permissions and Access in [Permission Sets](https://trailassembly.com/permission-sets-after-cancellation/) lists [record types](https://trailassembly.com/record-types/) as assignable and then parenthesises the constraint, not defaults. The metadata makes the same point structurally: the profile version of the record type structure carries a `default` flag (and a `personAccountDefault` flag), the permission set version carries only `recordType` and `visible`.

So the practical split on any object with record types is: profile sets the default record type and the layout that goes with each one, permission sets add the additional record types a persona needs. That works cleanly, and it is why a “minimal” profile is rarely completely empty — it still has to carry object settings for every object where a default matters.

## Page layout assignment is why minimal does not mean empty

Page layout assignment deserves separating from the rest because it scales with your data model rather than with your number of personas. Layouts are assigned per profile *per record type*, at Setup → Profiles → the profile → Object Settings, or the older Setup → Object Manager → object → Page Layouts → Page Layout Assignment.

The consequence is arithmetic. If two personas need different layouts on the same object and record type, they need different profiles — there is no other lever. That is the constraint that decides how many profiles you end up with, and it is worth working out deliberately before you start consolidating, because “we’ll get to three profiles” collapses the moment Sales and Sales Ops need different Opportunity layouts.

My own position: let layout requirements set the profile count, and treat every other difference between those profiles as a defect to be removed. A profile that exists because two groups need different layouts is legitimate. A profile that exists because someone needed Export Reports in 2019 is not.

## Tab settings look shared but are not quite

Both carry tab settings, but the labels differ, and the documentation says so outright: “tab settings labels in permission sets differ from the labels in profiles.” Profiles use Default On, Default Off, and Tab Hidden. Permission sets use Available, Available and Visible, and None.

None and Tab Hidden are not the same thing. None means this permission set grants nothing for that tab. Tab Hidden actually hides it. But since the same article states that “if a user has another permission set or profile with enabled settings for the same tab, the most permissive setting applies,” a Tab Hidden on the profile is overridden the moment any assigned permission set makes the tab Available. Tab Hidden is a default, not a restriction. Don’t use it as a control.

## One setting runs the other way

Worth knowing, because it breaks the mental model that profiles are the superset: external credential principal access is permission-set-only. `PermissionSet.externalCredentialPrincipalAccesses` exists as of API version 59.0; `Profile` has no equivalent field. Two others are also permission-set-only: `emailRoutingAddressAccesses` and `hasActivationRequired`, the latter being what makes session-based permission sets possible.

So if you are still granting integration access through profiles, the newer authentication model has already left without you. That is the clearest signal of where the platform is going: new capabilities are landing on `PermissionSet` and not on `Profile`.

## The working model

Salesforce’s Migrate from Profiles to Permission Sets article draws the line in one sentence: profiles are for “assigned apps, record types, page layouts, login hours, IP ranges, and password policies,” and permission sets are for “object, field, and user permissions as well as other access and feature settings.” That maps onto a practical arrangement:

### 1. Profiles become layout-and-login containers

Name them for what actually differentiates them, because that name will be the only reason anyone can tell them apart later. `Sales - Standard Layouts` beats `Sales User Modified`. Strip every object permission, field permission, and user permission out of them, keeping only page layout assignments, default record types, default app, and the login and session restrictions that genuinely differ by group.

### 2. Permission set groups carry personas

Build one group per job function and compose it from small, single-purpose permission sets. The reason to prefer groups over assigning eight permission sets directly is auditability: when someone asks why a user can delete Opportunities, “they’re in the Sales Manager group” is answerable and “they have these eleven permission sets” is not.

### 3. Login restrictions get a hard look before you copy them forward

Login hours and login IP ranges are the two profile-only settings that most often exist by accident, inherited from an implementation nobody remembers. They are also the two that generate the most support tickets, because a user travelling outside the IP range simply cannot log in. Confirm each one is still intentional rather than migrating it because it was there.

## Frequently asked

### Can a user have no profile, or more than one?

Neither. Permissions and Access Settings puts it plainly: “Every user is assigned only one profile, but can also have multiple permission sets.” The profile is required and singular, which is exactly why it cannot be eliminated.

### Can a permission set take away something the profile granted?

No. Permissions are cumulative. The documentation’s own example is that if Transfer Record is off in the profile but on in a permission set, the user can transfer records. The only mechanism that subtracts is a [muting permission set](https://trailassembly.com/permission-set-groups-and-muting/) inside a permission set group, and it only affects that group.

### If I can’t assign layouts with a permission set, how do I get to few profiles?

Count the distinct layout-and-record-type combinations your personas actually need on each object, not the personas themselves. Most orgs discover that far fewer combinations are genuinely different than the profile count suggests, and that consolidating layouts is the real work. Reducing profiles is a consequence of it.

### Do I still need to configure object permissions on profiles at all?

Not for access, but you do still touch Object Settings on the profile to set default record types and page layout assignments. That is why a minimal profile still has object-level configuration in it even though every permission checkbox is clear.

### Does the profile still control the user’s licence?

Yes. Each profile is bound to one user license type, and the Metadata API notes that every user must have exactly one user license. Changing someone’s licence therefore means changing their profile, which is a separate exercise from anything permission sets can do.

### Are session-based permission sets a way around profile session settings?

No. They solve a different problem. `hasActivationRequired` makes a permission set’s grants apply only while a session is activated, which is about scoping extra access in time. The session timeout that overrides your org-wide value is `ProfileSessionSetting`, and it stays on the profile.

---

*Reference: [Permissions and Access Settings](https://help.salesforce.com/s/articleView?id=platform.permissions_about_users_access.htm&language=en_US&type=5), [Migrate from Profiles to Permission Sets](https://help.salesforce.com/s/articleView?id=platform.migrate_profiles.htm&language=en_US&type=5), [Tab Settings](https://help.salesforce.com/s/articleView?id=platform.permissions_tab_settings_ref.htm&language=en_US&type=5), [Profile](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_profile.htm), [PermissionSet](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_permissionset.htm), [ProfilePasswordPolicy](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_profilepasswordpolicy.htm), and [ProfileSessionSetting](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_profilesessionsetting.htm) (Metadata API Developer Guide).*

---

Source: https://trailassembly.com/what-profiles-still-control/
Trail Assembly — independent Salesforce write-ups.