Profile and Permission Set

In Salesforce, a profile and a permission set are the two mechanisms that control what each user can see and do on the platform. They define access to objects, fields, tabs, apps, records and administrative functions, and they are the foundation of any well-built security model. This is part of what is designed and managed under Security.

The profile is required and unique: each user has exactly one, and it works as the minimum permission baseline (license type, login settings, defaults). The permission set is optional and cumulative: it is assigned on top of the profile to add extra access for specific users, without having to clone an entire profile. The practical rule is simple: the profile defines the common floor, permission sets add the exceptions. They never take anything away: they only grant.

Salesforce has long pushed customers to minimize profiles and rely on permission sets, because maintaining dozens of nearly identical profiles is an administrative nightmare. A good design uses a few base profiles and many modular permission sets that are combined according to each person's real role.

How the access model works

Access control in Salesforce is built in layers. The profile sets the floor: it defines the user license, the login hours and IP ranges, the defaults for creating records and a first level of object and field permissions. On top of that floor, permission sets add specific capabilities. Since both are additive, a person's final access is the sum of what their profile grants plus every permission set assigned to them. If something is not enabled in any of those layers, the user cannot do it.

It is essential to understand what this layer controls and what it does not. The profile and permission sets decide access to objects (create, read, edit, delete), to fields (which properties each person can see or edit) and to functions (exporting reports, using the API, managing users). On the other hand, who can access which individual records within an object is handled by another layer: organization-wide defaults, the role hierarchy and sharing rules. Confusing the two layers is one of the most common mistakes when designing permissions.

Profile vs permission set

The difference is easiest to understand with a direct comparison:

The practical takeaway: use the profile for what is structural and mandatory (license, login, defaults) and handle everything functional and variable with permission sets.

Why it matters for the business

A clean permission architecture is not just a technical topic: it is security, compliance and agility. It defines who can see sensitive customer data, who can export the entire database, who can touch critical configuration. A poorly built model leaves doors open (a sales rep who exports the whole customer portfolio the day they resign) or, the other way around, slows down operations because nobody has the access they need. In security audits or compliance processes, the first thing reviewed is what each person can do and why.

Concrete best practices

• Apply the principle of least privilege: each user gets only what their job requires, nothing more.
• Keep a few base profiles and delegate the variations to modular permission sets by function.
• Bundle related sets into a permission set group so you can assign them all at once.
• Document what each set grants: a name like "Export Sales Reports" is worth more than "PS_07".
• Review access periodically, especially when someone changes roles or leaves the company.

A concrete example (Argentina)

A consumer goods distributor in Buenos Aires has 40 sales reps, 5 supervisors and 2 administrators. Instead of creating three different profiles, it builds a single base profile, "Sales", with the standard license and login. On top of it, it assigns permission sets: supervisors get "View Team Pipeline" and "Approve Discounts", and administrators get "Manage Users" and "Export Reports". The day a rep is promoted to supervisor, the administrator does not touch their profile: they simply assign the two extra sets. A change that takes minutes, with zero risk of breaking everyone else's configuration.

Common mistakes

The most typical one is cloning profiles for every new nuance, until you end up with 30 nearly identical profiles that are impossible to maintain. Another is confusing this layer with the record layer: granting an object permission when the real problem was sharing. It is also common to forget to revoke access when someone leaves or changes departments, leaving orphaned permissions that are exactly what an audit flags. And the classic: granting "Modify All" or "View All" for convenience, wiping out all record-level security in one stroke.