If you’ve ever been part of a Salesforce implementation, you’ve probably hit this question at some point:

“Wait… what licenses do we actually need for everyone?”

And usually, that question comes up after you’ve already started buying them.

Licensing in Salesforce sounds simple at first. You look at the pricing page, pick an edition, assign users, and move on. But in reality, licensing decisions shape how your entire system works—who can access what, how teams collaborate, and honestly, how much you end up overspending.

And most teams get it at least partially wrong the first time.

Why this matters more than it seems

A Salesforce license isn’t just about access—it defines what someone can actually do in your system.

Salesforce even calls this out in their own documentation: different license types control access to objects, features, and overall functionality (see Salesforce user license types).

So when you assign a license, you’re not just giving someone a login. You’re shaping how they interact with your revenue process.

That’s why this tends to snowball. If licensing isn’t aligned to roles, you end up with people who either:

• have way more access than they need (and never use it), or
• don’t have enough to do their job properly

Neither one is great.

The most common mistake (we see this all the time)

Most teams default to giving everyone the same license.

Usually something like Sales Cloud Enterprise across the board.

It feels safe. It avoids edge cases. And it gets you moving quickly.

But it also means you’re paying for a lot of functionality that a big chunk of your team will never touch.

The better approach is to slow down for a second and ask:
what does each role actually need to do in Salesforce day to day?

Not theoretically. Not based on org charts. Based on real workflows.

What this looks like in practice

Sales reps are the easy one. They live in Salesforce. They need full access to accounts, contacts, opportunities, activities, and forecasting. This is where your standard Sales Cloud (Sales 360) licenses make total sense.

Where things start to get more interesting is everywhere else.

Sales leaders, for example, don’t necessarily use Salesforce the same way reps do. They’re not updating fields all day—they’re looking at pipeline, forecasts, and performance. They still usually sit on full licenses, but the value for them comes from visibility. This is often where teams start layering in analytics tools like Tableau or CRM Analytics to make the data actually usable.

Marketing is where we see a lot of over-licensing. Most marketing teams don’t need full CRM access. They’re primarily working in Agentforce Marketing (formerly Marketing Cloud) and syncing data into Salesforce. Giving them full licenses often adds cost without really improving how they work.

Salesforce itself positions Agentforce Marketing as a separate platform for managing campaigns, journeys, and engagement (see overview here). So forcing everything through core CRM licenses usually isn’t the most efficient setup.

Customer success teams are another one that depends heavily on your business model. If they’re purely support-focused, then Service Cloud (Service 360) licenses are the right fit. But if they’re involved in renewals or expansion, things get blurrier. Now they’re part of the revenue process, not just service, and your licensing—and system design—needs to reflect that.

Then you’ve got RevOps, admins, and system owners. These are the people building, maintaining, and evolving Salesforce. They typically need full access, but even here there’s nuance. Some users might be better suited for Salesforce Platform licenses, especially if they’re working with custom objects or internal workflows rather than core CRM features.

Salesforce explains this distinction pretty clearly in their platform overview: it’s not just a CRM—it’s an application platform. And not every user needs the full CRM layer.

And then there are executives.

This is probably the most over-licensed group in most organizations.

Executives don’t need to manage records or build reports. They need clear, reliable answers. In a lot of cases, that can come from dashboards, read-only access, or even external reporting tools. Giving every executive a full license often doesn’t change behavior—it just increases cost.

The part that gets overlooked

What trips teams up is thinking licensing is a one-time decision.

It’s not.

As your business evolves—new segments, new products, new motions—your licensing should evolve with it.

This is especially true as companies start layering in things like Data 360 (formerly Data Cloud) for unified data or exploring AI capabilities across the platform. These aren’t just product decisions—they impact how users interact with Salesforce and what access they actually need.

And if you don’t revisit licensing over time, you end up with a stack that reflects where you were, not where you are now.

How to think about this as a RevOps team

The goal isn’t to minimize licenses or cut cost at all costs.

It’s to create alignment.

Licenses should map cleanly to:

• how your revenue lifecycle actually works
• what each team is responsible for
• and how data flows across systems

When that alignment is there, everything else gets easier. Adoption improves. Reporting becomes more reliable. Costs stay under control without constant firefighting.

When it’s not, you start seeing symptoms—people working outside the system, duplicate tools popping up, constant confusion about where data lives.

And at that point, it’s not really a licensing problem anymore. It’s a system design problem.

Final thought

Licensing is one of those things that feels tactical, but it’s actually pretty strategic.

If you treat it like a checkbox during implementation, you’ll probably overspend and still end up with gaps.

But if you treat it as part of your RevOps architecture—something that reflects how your teams actually operate—you can build a system that’s both efficient and scalable.

And that’s usually the difference between Salesforce feeling expensive… and Salesforce actually driving value.