If you plan to sell a product on Salesforce, your company joins the ISV track itself and hires outside help only for the engineering. That’s the short answer to the question most product teams ask. A Salesforce ISV partner is the company that owns and sells an app built on the platform. A Salesforce consulting partner is a services firm that delivers project work for clients. The 2 roles solve different problems, and a product build usually needs both of them filled.
B2B SaaS teams usually hit this question when a customer asks for a Salesforce integration or a native app. The first instinct is to hire a well-known Salesforce consultancy. That works for projects inside your own org. It often goes wrong for a product, because packaging and the AppExchange security review call for skills that most implementation firms rarely use. This guide compares the 2 partner types and the costs of the ISV track. It also shows how to find a build partner that has shipped products before.
TL;DR
- A Salesforce ISV partner owns and sells an app on AgentExchange, the marketplace formerly called AppExchange. When you build a commercial product, your company becomes the ISV.
- A Salesforce consulting partner delivers projects inside a customer’s own Salesforce org, such as implementations and integrations.
- For product builds, look for a consulting firm with product development outsourcer (PDO) experience. These firms know how to package an app and get it approved.
- The ISV track carries a revenue share of 15% or 25% of net revenue, depending on the distribution model, plus $999 for each paid security review attempt.
- If only your own company will use what you build, a consulting partner is enough and the ISV track adds cost without a benefit.
What a Salesforce ISV Partner Is
A Salesforce ISV partner is a software company that builds a product on Salesforce and sells it to many customers. ISV stands for independent software vendor. The company joins the ISV track of the Salesforce Partner Program, builds an installable app or an API-based connector, passes the security review and lists the product on the marketplace. From then on, it handles licensing and support for every customer who installs it.
On the official side, Salesforce’s partner program page treats app building and consulting as separate tracks, and a company can join either one or both. The same page claims that AgentExchange ISV partners can shorten sales cycles by up to 20%. Salesforce doesn’t publish the method behind that figure, so treat it as a marketing claim and plan your sales cycle from your own data.
Many buyers search for a Salesforce ISV partner as if it were a vendor to hire. If you’re building the product, you are the Salesforce ISV partner. You own the namespace, the listing, the customer contracts and the revenue relationship with Salesforce. An outside firm can write code for you, but it can’t hold that role on your behalf without owning a piece of your product.
The term has a second meaning on the buyer side. When a company needs a capability inside its own org, an existing app may already cover it. Installing a listed app is often faster than commissioning a custom build. Check the marketplace before you scope any project, because the cheapest build is the one you don’t need.
The marketplace itself changed in 2026. Salesforce folded Slack Marketplace and the Agentforce ecosystem into AppExchange and renamed the result AgentExchange, which now lists more than 10,000 apps, according to SalesforceBen’s launch coverage of the change. Salesforce paired the launch with a $50M fund for ISVs. Many docs and Trailhead modules still use the AppExchange name, so you’ll see both terms for a while.
What a Salesforce Consulting Partner Is
A Salesforce consulting partner is a services firm that plans and delivers Salesforce projects for clients. Typical work includes implementation, integration, data migration, managed services and user adoption. The output lives inside 1 customer’s org, and the customer usually owns it under the contract.
Consulting partners are rated on customer results. Salesforce runs a separate consulting track with its own tiers and competencies, and buyers can filter partners by product and industry expertise when they search the marketplace. A firm’s tier tells you how it performs across its client base. A competency tells you where its team has proven delivery experience.
The skills that make a Salesforce consulting partner good at implementations don’t automatically carry over to products. A consultant configuring 1 org can rely on that org’s settings and its admin team. A product has to install cleanly into thousands of orgs with different permissions and customizations. It also has to keep working through 3 Salesforce releases every year without breaking any of those customers.
The new tier names help you read a firm’s standing quickly. Select marks partners with a proven delivery record that meet Salesforce’s program requirements. Summit marks the top performers on customer outcomes and satisfaction. Neither tier is a product credential, so a Summit firm with no shipped products is still a risk for a product build.
Many consulting firms do both kinds of work, and some do it well. The partner label only tells you which program track a firm joined. It doesn’t tell you whether the team has shipped a product through review. Ask for that evidence directly before you sign anything.
Salesforce ISV Partner vs. Consulting Partner at a Glance
The clearest difference is who owns the result. The table compares the 2 roles on the points that matter for a product build.
| Factor | Salesforce ISV Partner | Salesforce Consulting Partner |
| Who it is | The company that owns and sells the product | A services firm hired for project work |
| What it delivers | An installable app or connector for many customers | Code and configuration for 1 customer org |
| Who owns the IP | The ISV | Usually the client, as set by contract |
| How Salesforce earns from it | A share of net revenue from app sales | License sales to the customers it serves |
| Marketplace review | Security review before a public listing | No marketplace review |
| Program structure | ISV track with a marginal revenue share | Consulting track with Select and Summit tiers |
| Release burden | Stays compatible in every customer org, every release | Supports upgrades in 1 org |
Read the table as a split of responsibilities. The ISV side carries product risk and the revenue relationship with Salesforce. The consulting side carries delivery risk on a defined scope. A product build sits on the ISV side, even when an outside firm writes most of the code.
Product Development Outsourcers: The Partner Type Built for Product Work
The partner type that matches a product build is the Salesforce PDO, short for product development outsourcer. Salesforce’s commercial app development collection describes PDOs as consulting partners with experience building commercial apps for the marketplace. They can own the full build or take on a defined piece of it. Some simply add engineers to an existing product team.
A Salesforce PDO brings skills that implementation work rarely builds:
• Knowing which metadata can ship in a managed package and which settings stay with each subscriber.
• Designing for upgrades, since many packaged components are hard to change once customers install them.
• Setting up the License Management App and the Feature Management App for licensing and feature flags.
• Preparing code and documentation for the security review.
• Understanding ISV pricing and distribution models, which differ from end-customer license pricing.
You can find these firms by searching consultants on the marketplace and filtering for the AppExchange/PDO category. Public material on the 2026 program changes doesn’t make clear how PDO status maps to the new competency model. Verify any PDO claim by asking for listed products the firm helped build, then check those listings yourself.
A PDO doesn’t replace your role as the ISV. It works for you, inside your Partner Business Org, on your namespace. The best setups keep product decisions and the customer relationship with your team while the PDO handles engineering depth. That split also makes it easier to bring development in-house later.
The right time to hire your own engineers usually comes once the product has paying customers and a steady roadmap. At that point, product knowledge matters more than outside capacity. A good build partner plans for that handover from the start, with clear documentation and a codebase your new hires can read. Ask about past handovers when you first talk to a firm, because the answer shows how it treats client ownership.
How the 2026 Partner Program Changes Affect Your Choice
Salesforce rebuilt its consulting track in March 2026, and the changes affect how you read any partner’s credentials. Its partner program announcement replaced the old structure with 2 tiers, Summit and Select. The program also turned 170 legacy distinctions into 28 core competencies, with more weight on Agentforce and Data 360 skills.
The old tiers were Base, Ridge, Crest and Summit, so a vendor website that still shows Ridge or Crest badges is out of date. Industry analysts noted the scale of the reset. The Futurum Group analysis describes the move as a shift toward outcome-based delivery backed by larger financial incentives. For buyers, the practical result is simpler: competencies now carry more signal than tiers when you’re checking a firm’s fit.
The ISV side changed too. Salesforce opened Agentforce 360 to ISV partners and called it the biggest platform expansion for ISVs since Force.com launched 18 years earlier, according to its Agentforce 360 announcement for builders. Partners can now build on the same AI and data services that Salesforce uses for its own apps. A product built today may include agents and Data 360 features, so your build partner needs those skills as well as packaging experience.
Discovery on the marketplace is changing as well. Salesforce plans agentic search inside AgentExchange and Agentforce Builder, so customers may find apps through conversation as well as keyword search. A clear listing and well-documented features will matter more as that rolls out, which is one more reason to plan listing content with the build.
Some observers raised concerns about partners that don’t work with AI tools yet. SalesforceBen’s program overview called the overhaul close to an ecosystem reset centered on agentic work. If your product doesn’t use agents, that isn’t a problem. It does mean you should ask any consulting firm which competencies it holds today and which it lost in the transition.
What the ISV Track Costs
The ISV track costs little upfront and takes a share of revenue once you start selling. Salesforce calls its model Percentage Net Revenue, and the rate depends on the distribution model you choose. Revenue sharing starts only after you first report revenue, so a product in development pays nothing on that line.
For the actual percentages, Salesforce’s ISV starter pack lists 2 standard rates: 15% and 25% of net revenue. The higher rate typically applies when you bundle the platform license into your product, so customers buy 1 offer from you. At 15%, an app earning $500,000 in net revenue would pay Salesforce $75,000 for the year before any reduction.
Those reductions come from a marginal model that lowers the rate as your revenue grows. Salesforce introduced it as the Marginal Royalty Model in its 2020 program update, saying ISVs would get forward visibility into how margins expand as they grow. The current version is the AgentExchange Marginal PNR Model, and your Partner Account Manager can confirm the bands that apply to you.
| Cost Item | Amount | When It Applies |
| Revenue share | 15% or 25% of net revenue | After you first report revenue |
| Security review, paid or freemium app | $999 per attempt | Initial review and each resubmission |
| Periodic security re-review | $999 | When Salesforce re-reviews a listed paid app |
| Security review, free app | No charge | All review types |
The security review fee is lower than it used to be. Older documentation listed a $2,550 review fee plus a $150 annual listing fee. Even at $999, failed attempts add up, and each one also costs weeks of waiting. That’s why first-pass approval is the most useful number to ask a build partner about.
Build costs sit outside Salesforce’s fees, and they’re usually the largest line. Most build partners bill by fixed scope or by time and materials. Some also offer a dedicated team billed monthly. Fixed scope suits a well-defined first version. A dedicated team suits a product with a long roadmap, because the same engineers stay with your codebase and its review history.
Technical Work a Product Build Requires
A product build adds a layer of work that implementation projects rarely touch. Packaging and review prep take most of the effort before launch, and licensing work starts the day you go live. The sections below cover what to expect from a team that knows this work.
Packaging With Second-Generation Managed Packages
Second-generation managed packaging (2GP) is the model Salesforce now recommends for new products. In Salesforce’s 2GP comparison, a Dev Hub owns the packages, and Salesforce suggests turning on Dev Hub in your Partner Business Org. A first-generation packaging org can own only 1 managed package, while a Dev Hub can own several. Packages that share a namespace can also share code, and every packaging step can run through the Salesforce CLI.
That last point matters for cost. A team that automates packaging can build and test every release in a pipeline instead of clicking through orgs by hand. Ask your build partner to show you a pipeline it has run for another product.
Older products can move over. Salesforce’s 1GP conversion guide explains that a converted version inherits the listing readiness of a 1GP version that already passed review. Conversion works only for 1GP packages created with API version 57 (Spring ’23) or higher, and later conversions stay tied to the Dev Hub you used first.
Passing the AppExchange Security Review
The security review checks every listed solution before customers can install it. That includes API-only connectors as well as installable packages. The most common failure is well documented. Salesforce’s top 20 vulnerabilities post names missing object and field-level security checks (CRUD/FLS) as the top reason apps fail, by a wide margin. Sharing violations also rank near the top of the list.
Prevention is cheaper than resubmission. Salesforce’s guidance to prepare for review recommends running Salesforce Code Analyzer before you submit, and the review team expects scanner results with the submission. A build partner should run those scans in every sprint, so the code is ready for review long before the submission date.
Licensing and Support After Launch
Launch is the start of the ISV workload. Both 1GP and 2GP packages work with the License Management App and the Feature Management App. These tools control who can use your product and which features each customer gets. Packages also work with the Subscriber Support Console, which lets your team log in to customer orgs when a customer grants access.
Salesforce also runs periodic re-reviews of listed apps, and the fee applies to paid solutions each time. Plan support capacity for 3 platform releases a year. Each release can affect a packaged product in ways that only show up in some customer orgs.
When a Salesforce Consulting Partner Is Enough
A consulting firm is enough when only your company will use the result. Custom objects, flows, Apex code and integrations built for your own org never go through marketplace review. There’s no revenue share and no listing to maintain. You also skip the packaging discipline that products need, which keeps the project simpler and cheaper.
Common examples include connecting your Salesforce org to an internal billing system or migrating data from another CRM. A B2B SaaS company that wants its own revenue team on a cleaner Salesforce setup needs a consultant for that work. It doesn’t need the ISV track.
Internal projects can still borrow some product habits. Source-driven development keeps internal code organized as it grows. Ask your consultant whether the team uses version control and automated deployments, because those practices lower maintenance costs over time.
Some internal tools later turn into products. If there’s a real chance you’ll sell what you’re building, set it up like a product from day one. Join the ISV track early and register a namespace. Then keep the code in packages instead of loose metadata. Moving an internal build into a package later means reworking code that was never written for other orgs, and that rework often costs more than starting clean. The line moves when you start selling. If customers outside your company will install the code, the work belongs on the ISV track, whoever writes it.
When Your Company Needs the ISV Track
Your company needs the ISV track as soon as the code reaches customers outside your org. Several B2B SaaS situations put you there:
• You sell a native app or managed package to companies that already use Salesforce.
• Your SaaS product needs a listed Salesforce connector, including an API-only integration, because listed solutions must pass security review.
• You want to sell a full app to companies that don’t use Salesforce yet, with the platform license bundled into your price.
• You build agents or actions for Agentforce that you plan to sell on AgentExchange.
In each case, becoming a Salesforce ISV partner gives you the tools you’d otherwise lack. Those include a Partner Business Org and the packaging and licensing tools that products depend on. The ISV relationship also gives you a Partner Account Manager who can explain revenue share bands and listing options.
API-Only Connector or Native Package?
Many B2B SaaS companies start with an API-only connector, where most logic runs in their own platform and calls Salesforce through its APIs. This option keeps your core code in your own stack and lets your existing engineers do most of the work. It still needs a security review before you can list it, and your external endpoints get tested as part of that review.
A native managed package runs inside each customer’s Salesforce org. It can use Salesforce data and permissions directly, which customers often prefer for data residency and admin control. It also needs more Salesforce-specific engineering, so it’s where a Salesforce PDO adds the most value. Many products end up with both: a native package for in-org features and API calls back to the SaaS platform for heavy processing.
Working With an Outside Build Team
You don’t have to choose between the tracks for your build team. The common pattern is a hybrid. Your company holds the Salesforce ISV partner relationship, while a Salesforce PDO or a product-focused consulting firm writes much of the code. Your own product manager keeps the roadmap, and the outside team works inside your org and your namespace.
How to Vet a Build Partner
The best build partners can show you shipped products and explain their review history in plain numbers. Use these steps to compare firms on the same terms.
1. Ask for live listings. Request the marketplace listings the firm built, and confirm which company holds each namespace.
2. Ask about review history. Find out how many solutions the team took through the AppExchange security review and how many passed on the first attempt.
3. Check packaging depth. Ask whether the team builds 2GP packages through the CLI and can show a working release pipeline.
4. Match competencies to your product. Under the 2026 program, check whether the firm holds competencies in the areas your product uses, such as Agentforce or Data 360.
5. Test their upgrade plan. Ask how they test each managed package release against orgs with different settings before customers get it.
6. Clarify post-launch support. Confirm who handles patches and periodic re-reviews after launch.
7. Look at team training. Salesforce’s AppExchange partner trail takes about 8.5 hours and covers packaging and review prep, among other topics. It’s a reasonable baseline for every engineer on the team.
Watch for a few warning signs during these conversations. A firm that talks only about implementation case studies may not have product experience. A firm that wants to host your Dev Hub or namespace in its own org is asking for control you shouldn’t give up. Vague answers about review history usually mean the numbers aren’t good. Weigh the answers to steps 1 and 2 most heavily. A firm that can’t name a product it shipped is learning on your budget, whatever its tier or size.
Contract Terms to Settle Before the Build
Settle ownership in writing before any code is written. Product builds create assets that outlive the engagement, and some of them are hard to move later. Start with the namespace and the Dev Hub. Register both under your own Partner Business Org, so every package version belongs to your company from day one. If a partner’s org holds them, moving later is slow and sometimes impossible without disrupting customers. Ask for full access to the source repository and the release pipeline from the first sprint.
Next, check for conflicts of interest. Some firms that offer Salesforce PDO services also sell their own marketplace products. Add a clause that covers non-competing products and the reuse of code built for you. Make sure the contract states that you own all intellectual property created during the project.
Support terms deserve the same care. Define response times for customer issues, and decide who may log in to customer orgs through the support console. Customers will expect your company to answer for anything the outside team does in their orgs, so the access rules should match what you promise them.
Finally, write down who pays for and fixes failed reviews. Each resubmission costs $999 for a paid app, plus the time needed to fix the findings. A partner confident in its work should accept responsibility for remediation on code it wrote. Agree on a handover plan as well, including documentation and a knowledge transfer period, so your own team can take over the product when it’s ready.
Final Thoughts
The Salesforce ISV partner question has a clear answer once you separate roles from vendors. If you’re building a product to sell, your company becomes the ISV and owns the namespace and the revenue relationship. A consulting firm fits work that stays inside 1 org. For the build itself, look for a firm with real product experience, ideally a Salesforce PDO with listed products and a strong review record.
The 2026 program changes make credentials easier to read if you know where to look. Check competencies instead of old tier badges, and ask for proof of shipped products. Then lock down ownership in the contract before the first sprint. A product team that follows those steps can use outside engineering capacity and still keep full control of what it’s building.
FAQs
What Is the Difference Between a Salesforce ISV Partner and a Consulting Partner?
A Salesforce ISV partner owns and sells a product that many customers install. A Salesforce consulting partner is a services firm that delivers projects inside a client’s own org. The ISV carries product risk and shares revenue with Salesforce. The consulting partner carries delivery risk on a defined project scope.
Do I Need to Become a Salesforce ISV Partner to Sell an App?
Yes. To list and sell a commercial app on AgentExchange, your company joins the ISV track and passes the security review. You can still hire an outside firm to write the code, but your company holds the ISV relationship and the namespace.
Can a Consulting Partner Build My AppExchange Product?
Yes, if the firm has product experience. Many consulting firms build products for ISVs, and those with the right background are often called PDOs. Ask for listed products they built and their first-pass review record before you hire them.
What Is a Salesforce PDO?
A Salesforce PDO, or product development outsourcer, is a consulting firm with experience building commercial apps for the marketplace. A PDO can own a full build or add engineers to your team. It understands packaging and the security review, which most implementation work never touches.
How Much Does the AppExchange Security Review Cost?
The AppExchange security review costs $999 per attempt for paid and freemium solutions. Each resubmission after a failed review costs another $999, and periodic re-reviews of listed paid apps are charged too. Free solutions pay no review fee.
How Long Does the AppExchange Security Review Take?
Salesforce’s documentation says the review report arrives about 3 to 4 weeks after an initial submission. Failed reviews add more time, because you fix the findings and resubmit. Teams that scan their code during every sprint avoid most of those delays.
What Revenue Share Does Salesforce Take From ISV Partners?
Salesforce’s ISV starter pack lists 2 standard rates: 15% and 25% of net revenue, depending on the distribution model. The higher rate usually applies when the platform license is bundled into your product. A marginal model lowers the rate as your revenue grows.
What Changed in the Salesforce Partner Program in 2026?
In March 2026, Salesforce cut its consulting track from 4 tiers to 2, Summit and Select. It also replaced 170 distinctions with 28 competencies, with more emphasis on Agentforce and Data 360. On the ISV side, Salesforce opened Agentforce 360 to partners building products.
Is AppExchange Now Called AgentExchange?
Yes. In 2026, Salesforce folded Slack Marketplace and the Agentforce ecosystem into AppExchange and renamed it AgentExchange. The combined marketplace lists more than 10,000 apps. Many docs and training modules still use the AppExchange name, so expect to see both terms.
What Is a Managed Package?
A managed package is the container an ISV uses to distribute a product into customer orgs. It protects the ISV’s code and supports upgrades. Customers install it from the marketplace, and the ISV pushes new versions over time.
Should New Products Use First- or Second-Generation Packaging?
New products should use second-generation managed packaging. Salesforce recommends it, and every packaging step can run through the Salesforce CLI. Existing first-generation packages created with API version 57 or higher can be converted and keep their review status.
Why Do Apps Fail the AppExchange Security Review?
Missing object and field-level security checks are the most common reason, according to Salesforce’s own list of top vulnerabilities. Sharing violations are also frequent. Running Salesforce Code Analyzer before submission catches many of these issues early.
Who Should Own the Namespace for My Product?
Your company should. Register the namespace and the Dev Hub in your own Partner Business Org before the build starts. If a partner’s org holds them, moving later is difficult and can disrupt customers who already installed your product.
Can a Company Be Both an ISV and a Consulting Partner?
Yes. Salesforce lets companies join either track or both. Some firms sell their own products and also build products for clients. If you hire one, add contract terms that cover competing products and code reuse.
When Is a Consulting Partner Enough on Its Own?
A consulting partner is enough when only your own company will use what’s built. Internal integrations and data migrations stay inside your org. They don’t need a listing or a revenue share agreement with Salesforce.
