CIO Playbook: Managing ISV AppExchange App Licensing in Salesforce

Why AppExchange Licensing Belongs on the CIO Agenda

The Salesforce AppExchange hosts over 7,000 applications. By the time a large enterprise has been running Salesforce for five years, its platform is likely home to dozens of installed ISV apps — ranging from productivity tools installed by administrators to critical business applications procured through formal vendor processes. Most of these apps carry independent licensing obligations that operate entirely outside the enterprise's core Salesforce agreement.

The compliance exposure is material. ISV vendors can audit your usage through Salesforce's License Management App (LMA) or through their own telemetry. If an audit finds users accessing a managed package without corresponding licences, the enterprise faces back payment demands, penalty clauses, and renegotiation pressure at the worst possible moment. We have seen mid-market enterprises presented with six-figure true-up demands by ISV vendors who discovered unlicensed usage through LMA data they had always had access to but chose to act on only at contract renewal.

The cost case is equally strong. Across a typical enterprise Salesforce deployment, ISV application spend accounts for 15 to 30 percent of total Salesforce ecosystem costs — yet receives a fraction of the governance attention applied to the core platform. Rationalising, right-sizing, and negotiating ISV app licensing delivers savings that are disproportionate to the effort required.

The Dual-Subscription Reality

Installing an AppExchange application typically creates two parallel commercial relationships: one with Salesforce for the underlying platform access, and one with the ISV for the application licence. These subscriptions have independent renewal dates, independent pricing structures, and independent compliance obligations. Enterprises that manage only their core Salesforce contract while treating ISV apps as self-managing create a compliance and cost governance gap that grows with every new installation.

The situation is compounded by Salesforce's own commercial incentives. Salesforce charges ISV partners 15 percent of revenue for standard AppExchange apps and 25 percent for OEM embedded applications. This revenue share is built into ISV pricing, meaning enterprises are indirectly subsidising the Salesforce marketplace every time they purchase an ISV application. Understanding this dynamic matters during negotiation: ISV vendors carry a significant platform overhead that can be leveraged when negotiating multi-year commitments or enterprise-wide deployments.

AppExchange Licence Types: What You Are Actually Buying

Before you can govern ISV app licensing, you need to understand what types of licences AppExchange apps use and how they differ from standard Salesforce user licences. There are four primary licence structures you will encounter across the AppExchange catalogue.

Seat-Based User Licences

The most common ISV licensing model assigns a fixed number of licences to specific named users within your Salesforce org. When you purchase 100 user licences for an ISV application, those licences must be explicitly assigned to users within Salesforce. The licence count in your contract caps the number of assignable seats.

The compliance risk here is straightforward: if your administrators assign the ISV app to more users than the licence count covers, you are in breach. The more subtle risk is that many ISV apps use soft enforcement — the platform does not technically prevent over-assignment, leaving you reliant on internal controls to stay within licence limits. Soft-enforcement applications are audit targets precisely because vendors know that over-assignment is common in environments without active licence governance.

Site Licences

A site licence (configured in the LMA with a seat count of -1) grants access to every user in your Salesforce org, regardless of total headcount. Site licences are priced based on a negotiated flat fee or a headcount band, not per-user assignment. They eliminate the assignment management burden but introduce a different risk: as your total Salesforce user count grows, the site licence may need renegotiation upward, and ISV vendors will typically invoke a right-to-audit total user count on renewal.

Site licences are commercially advantageous for apps used by more than 60 to 70 percent of your Salesforce user population. For applications used by a narrow subset of users, seat-based licences are almost always cheaper.

Permission Set Licences

Permission set licences provide access to specific features or functionality within an ISV application without requiring a full user licence. They are commonly used for feature add-ons, premium tiers within an application, or access expansions for specific roles. Permission set licences require the same assignment discipline as seat-based user licences and carry the same over-assignment risk.

From a governance perspective, permission set licences are the most frequently overlooked licence type in enterprise Salesforce environments. They appear as separate licence records in your org that are not always surfaced in standard licence reporting, creating visibility gaps in your ISV licence inventory.

OEM Embedded Applications

OEM applications are built by Salesforce ISV partners who embed the Salesforce platform into their own products, selling to customers who may not otherwise have a Salesforce relationship. OEM applications use distinct licence types (Lightning Platform, Customer Community, Customer Community Plus) and operate under a different commercial structure where the ISV, not Salesforce, is the primary contracting party.

Enterprises that purchase OEM-embedded applications should be aware that the underlying Salesforce infrastructure is provided via the ISV's Salesforce contract, not your own. This has implications for data sovereignty, audit rights, and what happens if the ISV's own Salesforce relationship changes.

The ISV Compliance Risk Landscape

ISV compliance exposure in Salesforce environments comes from several directions. Understanding each risk category is the prerequisite for building effective governance.

Over-Assignment Without Enforcement

Many managed packages do not technically block administrators from assigning the application to more users than the licence count permits. The ISV's LMA tracks installation and assignment data in real time. Vendors who choose to act on this data — typically at renewal — can present back-payment demands covering the entire period of over-assignment, not just the current term. We have seen ISV vendors document three years of over-assignment and present true-up calculations that exceed the enterprise's total annual spend on the application.

The practical defence is not to rely on vendor grace, but to implement proactive licence assignment governance through your SAM tooling or Salesforce's own licence dashboards. Quarterly reconciliation between purchased licence counts and active assignments should be standard practice.

Unused Licences and Shelfware

The mirror risk to over-assignment is under-utilisation. Enterprises routinely carry ISV app licences for users who have left the organisation, moved to different roles, or simply never used the application after initial rollout. In our experience, 20 to 40 percent of ISV application licences in a typical enterprise Salesforce deployment are assigned to inactive or low-activity users.

Unused licences represent pure cost with zero value. At renewal, licence count optimisation based on actual usage data is one of the highest-return activities in ISV contract management. A licence count reduction of 25 percent, properly documented and presented with usage analytics, almost always succeeds — ISV vendors prefer to retain customers at reduced volume than lose the relationship entirely.

Shadow IT AppExchange Installs

AppExchange applications can be installed by any Salesforce administrator with sufficient permissions. In large organisations with distributed Salesforce administration, this creates a shadow procurement problem: applications are installed by departmental admins, sometimes purchased on departmental credit cards, without visibility from central IT, procurement, or legal. When these applications mature into business-critical tools, the enterprise discovers it has a commercial relationship it did not formally negotiate.

Governance frameworks should require that any AppExchange installation above free tier requires procurement review before installation, not after. Many organisations implement an AppExchange pre-approval process through their Change Advisory Board or Salesforce Centre of Excellence, requiring IT, security, and procurement sign-off for any paid application.

Licence Metric Mismatches

ISV applications sometimes define "user" differently from Salesforce's core licence definitions. An ISV may count any user who logs in during a calendar month as a licensed user, regardless of whether they are an active Salesforce user or how frequently they access the application. Others count by permission set assignment, not login activity. Understanding precisely how each ISV application defines and counts its licence metric is essential for accurate compliance and renewal negotiations.

The Salesforce License Management App and What Vendors See

CIOs and IT Asset Managers should understand what visibility ISV vendors have into your usage through Salesforce's own infrastructure. The Salesforce License Management App (LMA) is a Salesforce-provided tool that ISV partners install in their own Salesforce orgs to track licence allocation and usage across all their customer installations.

When you install a managed package from AppExchange, a licence record is automatically created in the ISV's LMA. The ISV can see the number of licences purchased, the number assigned, and — in many implementations — basic usage signals derived from the package installation data. This is not an independent audit tool; it is a continuous telemetry stream running from the moment of installation.

What the LMA Tracks

The LMA creates a lead record and a licence record for each customer installation. It tracks the seat count (number of licences purchased), the number of seats assigned, the package version installed, and the installation date. For packages that implement advanced LMA integration, the vendor may also receive feature usage signals that indicate which parts of the application are being actively used.

The practical implication is that ISV vendors already have real-time visibility into your licence assignment status. There is no element of surprise in an ISV licence audit — the vendor typically knows the compliance position before initiating any formal audit process. Disputes arise not because the data is unclear, but because the enterprise disputes the vendor's interpretation of what constitutes a required licence or challenges the remedy calculation.

Managing Your LMA Exposure

The appropriate response to LMA transparency is proactive governance, not reactive defence. Quarterly licence reconciliation should compare purchased counts against active assignments for every managed package in your environment. Any over-assignment identified internally should be remediated before it becomes a vendor-initiated discussion.

When over-assignment is identified and cannot be immediately remediated through licence reclamation, the commercially intelligent approach is to engage the vendor proactively and negotiate a prospective true-up as part of an early renewal, rather than waiting for the vendor to raise it on their timeline. Proactive engagement typically yields more favourable true-up terms than reactive response to a vendor-initiated audit.

Building an Enterprise ISV Licence Governance Framework

Effective ISV licence governance requires four interconnected capabilities: inventory visibility, usage analytics, commercial management, and renewal governance. Each capability is necessary; none is sufficient alone.

Capability 1: Inventory Visibility

You cannot govern what you cannot see. The starting point for ISV licence governance is a complete, current inventory of every managed package installed in every Salesforce org in your environment. This inventory should capture the application name, the ISV vendor, the licence type (seat-based, site, permission set), the purchased licence count, the current assignment count, the contract expiry date, and the procurement route (central IT, departmental, AppExchange direct).

For enterprises with multiple Salesforce orgs, this inventory must span every org. The Salesforce License Management tab in Setup provides a starting point for each org, but aggregating this across multiple orgs typically requires either a SAM tool with Salesforce integration (Flexera, Snow, ServiceNow SAM) or a custom reporting solution built on Salesforce's Tooling API.

Capability 2: Usage Analytics

Licence counts tell you what you have purchased and assigned. Usage analytics tell you whether those licences are being used. Salesforce provides native user login reporting and feature usage reporting through Lightning Usage App and the setup audit trail, but ISV application-specific usage reporting varies significantly by application.

For applications where the ISV provides usage dashboards, review these regularly and include usage data in every renewal discussion. For applications without native usage reporting, build a proxy metric using Salesforce's event monitoring capabilities to track whether users with the ISV application assigned are generating activity within the relevant features.

Usage data is your primary negotiating lever at renewal. An ISV vendor seeking to maintain current licence counts against documented evidence of 60 percent active utilisation has limited commercial justification for that position. Usage analytics convert an anecdotal "we think we have too many licences" into a specific, documented request for licence count reduction.

Capability 3: Commercial Management

ISV application contracts should be managed with the same rigour applied to your core Salesforce agreement. This means maintaining a contract register for every ISV application, including the subscription terms, pricing, renewal dates, auto-renewal provisions, licence metric definitions, and any overage or true-up mechanisms.

Auto-renewal clauses deserve particular attention. Many ISV application agreements include auto-renewal provisions with 30 to 60 day cancellation windows before the renewal date. An enterprise that misses the cancellation window and auto-renews an application it planned to terminate or renegotiate loses all leverage for the ensuing term. Calendar reminders set 90 days before each ISV renewal date, reviewed by both IT and procurement, should be a minimum control.

Salesforce's own annual uplift clause — typically 8 to 10 percent per year — cascades behaviorally into ISV pricing. ISV vendors who price their applications as a percentage of Salesforce list pricing will index their increases to Salesforce's own uplift. Watch for this structure in ISV contracts and negotiate a fixed annual uplift cap of 3 to 5 percent or a price-hold for multi-year commitments, independent of whatever Salesforce does to its own pricing.

Capability 4: Renewal Governance

ISV application renewals should be treated as structured negotiation events, not administrative renewals. The renewal process should include a usage review (is the application delivering value?), a licence count optimisation (are we licensed appropriately for actual usage?), a market benchmark check (are we paying competitive rates?), and a strategic question (does this application remain on our Salesforce roadmap, or is it a candidate for consolidation or replacement?).

Renewal governance should be owned jointly by the Salesforce platform team and central procurement, with input from the business units that use the application. Procurement brings commercial discipline and market knowledge. The Salesforce team brings usage data and technical context. Business units provide the value assessment that determines whether licence reduction or full termination is the right outcome.

Negotiating ISV AppExchange Licensing: Ten Levers

ISV application negotiation follows different dynamics from core Salesforce contract negotiation, but the principles are the same: preparation, data, and timing create leverage. Here are the ten most effective negotiation levers for ISV AppExchange licensing.

1. Usage Data as Primary Evidence

Enter every ISV renewal with documented usage analytics covering at least the previous 90 days. Active user counts, feature utilisation rates, and login frequency data directly challenge the vendor's assumption that you will renew at current licence counts. Vendors who know you have usage data are far less likely to propose increases than vendors who assume you are managing licences by intuition.

2. Competitive Alternatives

Most AppExchange application categories have multiple competing solutions. Identifying and engaging one or two credible alternatives before an ISV renewal — even without a firm intent to switch — materially changes the negotiation dynamic. ISV vendors who perceive no competitive threat have little incentive to offer pricing concessions. Those who know you have evaluated alternatives and have a credible switching path will price to retain you.

3. Multi-Year Commitments for Discount

ISV vendors value revenue predictability. A two or three year commitment at current licence counts or slightly reduced counts typically unlocks discounts of 15 to 25 percent relative to annual renewal pricing, plus an annual uplift cap of 3 to 5 percent rather than the standard 7 to 10 percent. The discount for multi-year commitment on ISV applications is often larger, proportionally, than on core Salesforce licences — precisely because ISV vendors have less pricing infrastructure and more flexibility to negotiate individually.

4. Bundle Negotiations with Core Salesforce Renewal

When your core Salesforce agreement is approaching renewal, use the moment to consolidate ISV renewal discussions. Large Salesforce customers who are simultaneously negotiating a SELA or major platform renewal have heightened leverage with ISV vendors who want to protect their AppExchange position. Some ISV vendors will offer significant concessions on pricing or terms specifically to avoid being displaced during a platform consolidation discussion.

5. True-Up Negotiation Strategy

When a vendor presents a true-up demand — whether through formal audit or informally at renewal — do not accept the initial calculation. True-up demands based on LMA data should be scrutinised for accuracy, metric interpretation, and remedy calculation. The vendor's initial true-up demand typically reflects a maximalist position, not a firm legal claim. Negotiate the period covered, the licence metric interpretation, and the remedy amount before agreeing to any payment.

6. Right to Audit Reciprocity

ISV application contracts frequently include broad audit rights for the vendor with minimal procedural protections for the customer. Negotiate for reciprocal audit protections: reasonable notice periods (30 to 60 days), limits on audit frequency (no more than once per calendar year), a requirement that the vendor share audit methodology before commencing, and a dispute resolution mechanism if audit findings are contested. These protections do not prevent legitimate compliance review but prevent surprise audit demands designed to create settlement leverage.

7. Licence Pooling and Org Flexibility

Enterprises operating multiple Salesforce orgs — production, sandbox, development, regional — should negotiate the ability to use a single ISV licence pool across all orgs without separate licence counts for each. This is particularly important for applications that are used in both production and testing environments. ISV vendors sometimes attempt to count sandbox usage against licence limits; negotiate explicit exclusions for non-production environments in your contract.

8. Exit and Portability Rights

Negotiate data export and portability rights into every ISV application contract. If the vendor ceases operations, is acquired, or loses Salesforce partner status, you need contractual assurance that you can export your data in a standard format within a defined period. Acquisition risk is particularly relevant in the AppExchange ecosystem, where ISV consolidation by Salesforce or third-party acquirers has become increasingly common.

9. Shelfware Reclamation at Renewal

Document unused licences — those assigned to inactive users, duplicate orgs, or roles that no longer require the application — and present this as a formal licence reclamation request at renewal. A licence count reduction of 20 to 30 percent backed by documented inactivity data is a standard renewal outcome for well-governed AppExchange contracts. Vendors who resist reasonable reclamation requests should be treated as negotiating in bad faith and escalated to a competitive review process.

10. Salesforce Fiscal Year End Timing

Salesforce's fiscal year ends January 31. ISV partners who build their businesses on the AppExchange ecosystem typically align their own financial targets to Salesforce's fiscal calendar, because Salesforce marketplace incentives and ISV partner certifications operate on this timeline. Negotiating ISV renewals in January — specifically the last two weeks of January — creates end-of-fiscal-year urgency for ISV vendors seeking to close revenue before January 31. This timing often produces the deepest discounts available in a given year.

Integrating ISV Governance into Your Salesforce Centre of Excellence

The most sustainable ISV licence governance model operates through a Salesforce Centre of Excellence (CoE) that integrates commercial governance, technical oversight, and business stakeholder engagement. Enterprises that manage ISV compliance purely through central IT without business unit input make poor renewal decisions because they lack the value context to distinguish high-utilisation applications from shelfware. Enterprises that leave ISV governance entirely to business units produce inconsistent commercial outcomes and create shadow procurement risks.

An effective CoE structure for ISV governance includes a platform owner who maintains the master ISV inventory and renewal calendar, a procurement representative who manages commercial negotiations and contract terms, IT Asset Management representation for SAM tool integration and compliance reporting, and a rotating business unit liaison who provides usage and value input for the applications their function uses.

This cross-functional structure should meet quarterly to review the ISV licence landscape: upcoming renewals, compliance status, usage trends, and any applications identified for consolidation or replacement. The quarterly cadence ensures that renewal negotiations are never conducted under time pressure, and that licence count decisions reflect current business reality rather than historical assumptions.

SAM Tool Integration

Connecting your Software Asset Management tool to Salesforce via API integration is the foundation of scalable ISV licence governance. SAM platforms including Flexera One, Snow License Manager, and ServiceNow SAM Pro all offer Salesforce connectors that pull installed package data, licence assignment counts, and user activity information from each Salesforce org on a scheduled basis.

This integration provides automated licence utilisation reporting, alert thresholds for licence ceiling approaches, and consolidated renewal calendars that aggregate ISV renewal dates across all Salesforce orgs. For enterprises with a large Salesforce footprint, SAM tool integration is the difference between manual governance that inevitably develops gaps and systematic governance that catches compliance issues before they become commercial liabilities.

AppExchange Governance in a SELA Environment

Enterprises operating under a Salesforce Enterprise License Agreement (SELA) face a particular ISV governance challenge: the SELA provides broadly unlimited access to core Salesforce products, which can create a false sense that the entire Salesforce ecosystem — including AppExchange apps — operates on an unlimited basis. It does not.

SELA coverage is defined by the specific product entitlements negotiated in your agreement. AppExchange applications from third-party ISV vendors are not included in a Salesforce SELA, regardless of how broadly the SELA defines its product scope. Each ISV application retains its own independent licensing requirement, even if the Salesforce platform users access from is covered by your SELA.

In fact, SELA environments often have more ISV compliance exposure than standard licence environments, because the broadly unlimited feel of the platform encourages administrators to install and enable ISV applications without the licence-count discipline that seat-based environments impose. A quarterly ISV licence audit is even more important in SELA environments for this reason.

Similarly, when Salesforce itself acquires a previously independent ISV application and incorporates it into the platform — as happened with MuleSoft, Tableau, Slack, and elements of Data Cloud — the licensing terms for that application change. Applications that were previously licensed independently may be brought under SELA coverage in subsequent renewals, or may be offered as optional add-ons with consumption-based pricing. Tracking these transitions and updating your ISV inventory accordingly is a governance task that requires active monitoring of Salesforce's product announcements and licensing changes.

Nine Priority Actions for CIOs

1. Conduct a full ISV inventory audit within 90 days. Document every managed package installed across all Salesforce orgs, including licence type, purchased count, assigned count, and renewal date. This baseline is the prerequisite for everything else.

2. Implement quarterly licence reconciliation. Compare purchased counts against active assignments for every managed package every quarter. Identify and remediate over-assignment before vendors act on LMA data.

3. Build a renewal calendar with 90-day lead time. Map every ISV application renewal date and set procurement review triggers at 90 days and 30 days before each renewal. Never auto-renew without deliberate review.

4. Connect your SAM tool to every Salesforce org. SAM tool integration provides the automated visibility required for scalable ISV governance. Manual governance fails in proportion to the number of installed applications and Salesforce orgs.

5. Establish pre-installation approval for all paid apps. Require IT, security, and procurement review before any paid AppExchange application is installed. This prevents shadow procurement and ensures every commercial relationship is actively managed from inception.

6. Include usage analytics in every renewal negotiation. Never approach an ISV renewal without 90 days of documented usage data. Usage evidence is your primary lever for licence count optimisation and renewal pricing.

7. Negotiate audit protections into every ISV contract. Require notice periods, frequency limits, methodology disclosure, and dispute resolution mechanisms for any vendor audit right. These protections are standard in mature ISV contracts and should be non-negotiable.

8. Evaluate ISV applications in the context of your SELA or multi-cloud strategy. As Salesforce continues acquiring ISV partners, applications currently licensed separately may become part of your core Salesforce entitlement. Monitor product acquisition announcements and update your renewal strategy accordingly.

9. Time major ISV renewals to January. Salesforce's fiscal year ends January 31. ISV vendors aligned to Salesforce's fiscal calendar are most motivated to close deals in the last two weeks of January, creating an annual window for the best available pricing.