Salesforce Licensing Models Explained: Per User, Per Login, Per OrgCore Licensing Mechanics Every Enterprise Must Understand Before Signing

Why the Licensing Model You Choose Matters More Than the Price You Pay

Most enterprise procurement teams fixate on the per-unit price during a Salesforce Salesforce negotiation tipsion and overlook a far more consequential decision: which licensing model applies to each user population. Salesforce does not operate a single, monolithic Salesforce pricing 2026 structure. Depending on the product, the user type, and the deployment context, you will encounter per-user (named seat) licensing, per-login (consumption) licensing, and in certain product lines, per-org (capacity or flat-fee) licensing. Each model carries different cost drivers, different scaling characteristics, and different contractual traps. An organisation that assigns full CRM seats to users who only need quarterly portal access is burning money just as surely as one that selects a login-based model for a user base that authenticates daily.

The financial impact is not hypothetical. We routinely encounter enterprises spending $500,000 or more per year on Salesforce licences that could be restructured — without reducing any functional capability — simply by mapping the correct licensing model to each user cohort. The purpose of this guide is to give CIOs, IT asset managers, and procurement leaders the mechanical understanding required to make that mapping correctly, and to negotiate the resulting contract with confidence. For organisations needing a structured approach to this analysis, our Salesforce Licence Optimisation Calculator provides a useful starting framework.

“The single most expensive licensing decision in Salesforce is not which edition you buy — it is applying the wrong licensing model to the wrong user population. Get that wrong, and no amount of discount negotiation will save you.”

Model One: Per-User (Named Seat) Licensing

How It Works

The per-user model is Salesforce’s default and most familiar licensing construct. Every individual who requires access to the Platform licensing is assigned a named licence, billed on a per-user, per-month basis, with contracts typically invoiced annually in advance. The user’s identity is tied to the licence — sharing credentials between individuals is a contractual violation. This model applies across the core CRM products: Sales Cloud, Service Cloud, the Salesforce Platform, and most industry-specific clouds.

Within the per-user model, Salesforce operates an edition hierarchy that determines both the feature ceiling and the price point. As of early 2026, the primary tiers for Sales Cloud and Service Cloud follow a clear escalation pattern: the Starter Suite begins at $25 per user per month, the Pro Suite at $100, Enterprise Edition at $175, Unlimited Edition at $350, and the new Agentforce licensing guide Edition at $550. Each successive tier unlocks additional customisation, automation, API capacity, and AI functionality. Note that Salesforce implemented a roughly 6% price increase across Enterprise and Unlimited Editions in August 2025, and further incremental uplifts should be expected at renewal.

The Edition Lock-In Trap

A critical mechanical detail that many organisations overlook: all users within a Salesforce org must operate on the same edition. You cannot have fifty Enterprise users and thirty Pro Suite users within a single org. This means the decision to upgrade even one user population to a higher edition forces every licence in that org to the higher price tier. For a 500-seat organisation, moving from Enterprise to Unlimited to accommodate a requirement that affects only a dozen power users represents a cost increase of $1,050,000 per year — an amount that would fund an entire separate platform instance. Understanding multi-org versus consolidation strategies is therefore essential before committing to an edition upgrade.

Platform Licences: The Per-User Model at a Lower Price Point

Not every internal user needs access to core CRM objects like Leads, Opportunities, Cases, or Campaigns. Salesforce offers Platform Starter licences at approximately $25 per user per month and Platform Plus licences at approximately $100 per user per month. These licences permit access to custom applications built on the Salesforce Platform, including custom objects, reports, dashboards, and automation tools like Flow — but they deliberately exclude the standard CRM modules. For organisations that have built internal operational applications on Salesforce and need to extend access to non-sales and non-service users, Platform licences represent a substantial cost avoidance opportunity.

When the Per-User Model Is Optimal

The named-seat model works well when users authenticate frequently (daily or near-daily), when they require persistent personalised configurations such as dashboards, reports, and workflow rules, and when the user population is relatively stable and predictable. Sales teams, service agents, and operations staff who live in Salesforce throughout the working day are the archetypal per-user populations. The model becomes problematic — and expensive — when applied to populations that access Salesforce sporadically, such as external partners, customers, or seasonal workers. For those populations, the per-login model almost always delivers a better economic outcome.

Model Two: Per-Login (Consumption-Based) Licensing

How It Works

The per-login model charges the organisation based on the number of authentication events rather than the number of named individuals. Under this model, you purchase a monthly pool of logins, and each time a user authenticates to the platform, one login is consumed from the pool. The model is available primarily through Salesforce Experience Cloud (formerly Community Cloud), and it represents one of the most powerful — yet widely misunderstood — cost levers in the Salesforce portfolio.

Experience Cloud offers two purchasing models for external user populations: member-based (named user) and login-based (consumption). Under the member-based model, each external user is assigned a named licence with unlimited access, similar to an internal user. Under the login-based model, you purchase a block of logins that are shared across your entire external user pool, and any individual user can consume a login from that pool each time they authenticate. A detailed breakdown of these structures is available in our CIO Playbook for Licensing External Users in Experience Cloud.

Pricing Mechanics

The list pricing for Experience Cloud login-based licences varies by the licence tier. Customer Community logins are priced at approximately $2 per login, while Partner Community logins are approximately $10 per login. These figures represent list prices; enterprise agreements frequently achieve 20–40% discounts depending on volume commitments and contract duration. The corresponding member-based licences for Customer Community start at approximately $5 per member per month and for Partner Community at approximately $25 per member per month.

The Four-Login Threshold Rule

The critical decision point between login-based and member-based models is frequency of access. The widely cited four-login rule of thumb holds that if an individual user authenticates more than four times per month, a member-based (named) licence becomes more economical than consuming four logins from the pool. Below four logins per month, the login-based model wins. This threshold, however, depends heavily on the actual negotiated prices for your specific contract. If you have secured a deep discount on login-based pricing but paid list for member licences, the crossover point may be six or eight logins per month.

When the Per-Login Model Is Optimal

Login-based licensing excels for large external user populations with low individual frequency — classic examples include customer self-service portals where thousands of customers may have accounts but most log in only once or twice per quarter, supplier portals where vendors check order status periodically, or partner communities where a broad network of partners accesses deal registration features infrequently. The model is particularly powerful when combined with guest user access for purely public content, which consumes no logins at all. Understanding the interplay between guest access, login-based, and member-based models is essential for optimising community licensing costs at scale.

Conversely, the login model becomes expensive and administratively painful when applied to user populations that authenticate daily or near-daily. A partner population of 100 users who each log in 20 times per month would consume 2,000 logins. At $10 per login, that is $20,000 per month — compared to $2,500 per month on member-based licences at $25 each. Getting the model wrong by even a modest margin can produce a cost differential measured in hundreds of thousands of dollars annually for large enterprises.

Model Three: Per-Org (Capacity or Flat-Fee) Licensing

How It Works

The per-org model charges a flat fee for access to a capability or a capacity allocation, irrespective of how many individual users utilise it. This model does not appear across Salesforce’s core CRM products but is increasingly significant in its data, analytics, AI, and infrastructure offerings. The distinguishing characteristic is that cost scales with capacity, data volume, or organisational entitlement rather than headcount.

The most prominent examples of per-org pricing within the Salesforce ecosystem include Data Cloud, which is priced based on the volume of data records ingested and stored rather than the number of users querying it; Marketing Cloud, where pricing is driven by the number of contacts in the database and the monthly message volume rather than named user seats; and certain Salesforce add-ons capacity packs for storage, API calls, and sandbox environments. Salesforce’s newer Agentforce Flex Credits model also follows a consumption pattern at the org level, where organisations purchase blocks of 100,000 credits at $500 (roughly $0.10 per action) that are consumed across the organisation without per-user attribution. Our analysis of Salesforce AI and Data Cloud licensing provides a deeper examination of these emerging models.

Per-Org Product Pricing Examples

The Hidden Per-Org Costs That Inflate Total Spend

The per-org model is where many enterprises encounter unexpected cost escalation, because these charges compound on top of per-user and per-login fees. Every Salesforce edition includes a base allocation of data storage (typically 10 GB plus a per-licence increment), file storage, and API calls. Once those thresholds are exceeded, the organisation pays overage fees that are billed at the org level. Storage and API usage management is therefore a critical discipline for any enterprise running Salesforce at scale. We have seen organisations paying $50,000–$150,000 per year in storage overages alone, often because no one mapped the storage allocation to the actual data growth trajectory during the initial contract negotiation.

When the Per-Org Model Is Optimal

Per-org licensing is effectively unavoidable for the products that use it — you do not get to choose an alternative model for Data Cloud or Marketing Cloud. The optimisation opportunity lies in how you negotiate and manage capacity. The key principles are: right-size the initial capacity commitment based on realistic projections rather than Salesforce’s suggested volumes; negotiate tiered pricing that reduces the per-unit cost as volume grows; build in contractual flexibility to scale capacity up or down at defined intervals; and maintain active usage monitoring to avoid both over-provisioning and surprise overages.

Choosing the Right Model for Each User Population

The most effective Salesforce licensing strategies do not rely on a single model. They map each distinct user population to the model that delivers the lowest cost at the required level of access. The segmentation process begins with a comprehensive inventory of every individual and system that interacts with Salesforce, categorised by three dimensions: frequency of access, breadth of functionality required, and whether the user is internal or external to the organisation.

Negotiation Implications by Model

Each licensing model presents different pressure points during Salesforce contract termss (typically 7–10% annual uplift caps versus 10–15% if left uncapped), and co-terming provisions that align add-on licences with the primary contract renewal date. Critically, Salesforce contracts typically restrict mid-term reductions — you can add seats during the term (pro-rated), but you cannot reduce them until renewal. This asymmetry means the initial seat count must be conservative, with growth provisions built into the agreement rather than over-committed upfront. For a structured approach to these discussions, our CIO Playbook for Negotiating Salesforce Contracts provides the tactical framework.

For per-login contracts, the negotiation focus shifts to the unit price per login, the minimums and true-ups playbook monthly commitment, and whether unused logins roll over to subsequent months. Most standard Salesforce agreements do not permit login rollover, meaning that a block of 10,000 logins purchased for January expires unused if only 6,000 are consumed. Negotiating rollover provisions, or at minimum reducing the committed monthly minimum, can save 15–25% on the total login-based spend. It is also worth negotiating the right to convert between login-based and member-based models mid-term without penalty, as your usage patterns will inevitably evolve.

For per-org contracts, the most important negotiation points are growth corridors (agreed pricing for future capacity increases), burst provisions (temporary capacity expansions without permanent commitment increases), and clear overage pricing caps. Marketing Cloud contracts in particular should include negotiated tier pricing for contact volume growth, with automatic step-downs in per-contact cost as the database scales. Organisations approaching a Salesforce renewal should ensure all three model types are reviewed holistically rather than negotiated in isolation.

Compliance and Audit Considerations

Salesforce reserves the right to audit licence compliance under the terms of its Master Subscription Agreement, though it exercises this right far less aggressively than vendors like Oracle or SAP. Nevertheless, the three licensing models each create distinct compliance exposures. In the per-user model, the primary risk is credential sharing — multiple individuals accessing the platform under a single named licence. In the per-login model, the risk is under-purchasing login packs, resulting in users being denied access or the organisation exceeding its contracted allocation. In the per-org model, the risk is exceeding storage, API, or data volume limits without a corresponding contractual entitlement.

Maintaining ongoing visibility into actual usage across all three models is not optional — it is the foundation of both cost optimisation and compliance defence. Salesforce provides native tools such as the Login History report, the Company Information page (which displays licence consumption), and Storage Usage dashboards. For enterprises managing complex multi-cloud Salesforce deployments, third-party IT asset management platforms or dedicated audit readiness programmes are advisable. The cost of proactive licence management is trivial compared to the cost of a true-up invoice triggered by a Salesforce compliance review.

Emerging Models: Agentforce and AI-Driven Licensing

Salesforce’s entry into agentic AI through Agentforce has introduced genuine pricing model experimentation. Within roughly eighteen months, Salesforce shipped three distinct pricing structures for the same product: an initial $2-per-conversation model at launch, a Flex Credits model at $0.10 per action in mid-2025, and a per-user licence starting at $125 per user per month through the Agentic Enterprise Licence Agreement (AELA) in late 2025. All three models currently coexist, and Salesforce allows customers to select the model that best fits their consumption pattern.

For procurement teams, this multi-model approach is both an opportunity and a hazard. The opportunity lies in selecting the model that matches your actual AI consumption profile — organisations with predictable, high-volume agent interactions may benefit from per-user AELA pricing, while those in experimental or low-volume phases may prefer the pay-per-action Flex Credits model. The hazard lies in committing to a model before you have sufficient usage data to forecast accurately. Our strong recommendation is to begin with Flex Credits to establish a consumption baseline, then evaluate whether a per-user AELA commitment delivers savings once usage patterns stabilise. The broader strategic implications of these AI licensing structures are examined in our Salesforce Einstein and Agentforce CIO Playbook.

Building a Total Cost Model Across All Three Licensing Types

The most sophisticated enterprise Salesforce customers model their total cost of ownership by aggregating all three licensing models into a unified view. The per-user component covers internal CRM and Platform users. The per-login component covers external Experience Cloud users. The per-org component covers data, storage, API, marketing, and AI capacity. Each component has different cost drivers, different growth trajectories, and different negotiation levers.

Building this unified model requires collaboration between IT asset management, procurement, finance, and the Salesforce administration team. The Salesforce Total Cost of Ownership Calculator can serve as a starting template, but the real value comes from populating it with your organisation’s actual usage data, contracted rates, and projected growth scenarios. Run the model at minimum annually — and always in advance of a renewal cycle — to identify opportunities for model switching, licence rebalancing, or renegotiation. Organisations that treat licensing minimums and true-ups as a continuous governance function rather than a periodic exercise consistently achieve lower total Salesforce costs.

Frequently Asked Questions