6 posts tagged with "Profiles & Permissions"

In Salesforce, every user has exactly one profile and can have many permission sets. A profile sets the baseline — and the settings that can only have one value per user, like default app, record types, page layout assignments, and login hours. A permission set grants additional access on top and stacks additively, so you can assign the same set to many users. The model Salesforce now recommends is minimal profiles plus permission sets (composed into permission set groups), and that's where the ecosystem is heading — though, as of 2026, there's no deadline forcing it.

You've got a batch of new objects to move from sandbox to production, but you're not ready to give users access to them yet. The natural plan: deploy the objects now, deploy the permissions later. The natural worry: if you include profiles, do you grant access too early — or worse, overwrite production's profiles wholesale?

You can absolutely split it: deploy the objects with no profile in the package, and Salesforce's own default keeps every user's access at none until you deploy a profile later. The trick is doing it without the two traps that make people nervous.

You want to push one change — a profile should use a different page layout for an object — from one org to the next, ideally across many orgs at once. The short answer: no, you don't need to deploy the whole profile. A page layout assignment is a single entry on the profile (<layoutAssignments>), and the Metadata API upserts a profile per element, so a profile containing just that one assignment deploys fine and leaves the rest of the target profile untouched. That still leaves the questions every admin automating this runs into: will it wipe my other assignments? Do I need the layout and the record types too?

Ask how to deploy a Salesforce profile — the System Administrator profile especially — and you'll get a chorus of warnings: it wipes permissions, it comes over empty, it strips your settings. The fear is earned. The Metadata API reads a profile as a single all-or-nothing document, so the way you deploy it decides whether you ship a clean change or a mass lockout — and the safest way is to scope the profile to only the components you're deploying, so anything you didn't include is never touched on the target.

You deploy a profile or permission set to another org and Salesforce throws it straight back:

Unknown user permission: SendExternalEmailAvailable

The profile is valid and the permission is real; the target org simply doesn't recognize the name. That's because the permission only exists in an org once the feature behind it is turned on — here, SendExternalEmailAvailable needs Email Deliverability set to "All emails" — and the same cause is behind every "Unknown user permission" error.

Profiles in Salesforce are powerful... and frustrating. They define what users can see and do, but managing them across environments has long been a complex task for admins and developers. If you’ve ever tried to change the license type of a profile, migrate a community profile to internal users, or even just clone an existing profile with slight modifications, you’ve likely hit a wall of Salesforce limitations.

The new Profile Cloner in mtdt.io is built to change that.