Category: Blog

For Salesforce ISVs, a successful AgentExchange launch involves more than building a useful product and passing the Salesforce security review. Before a managed package or native integration can reach the market, Salesforce also needs to understand the company behind it: how the business operates, how customers will buy, and whether the team can support the solution over time.

Salesforce has renamed AppExchange to AgentExchange. AgentExchange is the new name for the Salesforce marketplace formerly known as AppExchange. The underlying ecosystem still includes Salesforce apps, managed packages, integrations, and agent solutions. The name change reflects Salesforce’s broader agentic strategy, but the practical ISV onboarding, business plan review, security review, listing, and distribution concepts remain relevant.

That is the purpose of the AgentExchange business plan review, often called the Salesforce BPR.

The BPR is not necessarily a traction review. An ISV does not automatically need existing customers, installs, or a large revenue history to move forward. The more important consideration is whether the company presents a coherent and credible operating model.

In this guide, we explain 9 practical ways to prepare for the AgentExchange business plan review, while also addressing how it relates to Salesforce partner onboarding and the AgentExchange security review. Salesforce processes can change, so confirm current requirements, sequencing, commercial terms, and submission steps in Partner Community or Partner Console before relying on any published guide.

1. Understand where the business plan review fits

Salesforce ISV onboarding includes several connected activities:

1. Joining the Partner Community and beginning partner onboarding.
2. Establishing the company and commercial relationship with Salesforce.
3. Preparing the product, package, integration, listing, and security materials.
4. Completing business approval or business plan review activities.
5. Completing the security review and satisfying the remaining publication requirements.

The exact sequence may depend on the solution type, distribution model, partner status, and current Salesforce process. Salesforce’s AppExchange, now called AgentExchange, ISV onboarding guide describes business approval and security preparation as related stages on the path to publication.

Do not treat a reported review period or fee as a universal rule. Salesforce’s official security review documentation currently describes security reviews as potentially taking several weeks. Commercial terms and fees may also depend on the solution and distribution model.

Prepare for the BPR and technical review in parallel, then confirm the current dependency order with your Salesforce onboarding contact.

Schedule a Call with CloudStreet to discuss an AgentExchange readiness plan before you submit.

2. Present a clear business model

Salesforce needs to understand how your company expects to create and sustain a business around the product. A concise business model should answer six questions:

1. What problem does the product solve? Describe the operational or financial problem in business terms.
2. Who experiences the problem? Define the ideal customer profile by industry, company size, Salesforce edition, role, or use case.
3. How will customers pay? Explain subscription, usage-based, per-user, per-org, freemium, or add-on pricing.
4. How will customers find you? Describe direct sales, content, referrals, implementation partners, events, or Salesforce ecosystem channels.
5. How will you acquire early customers? Explain pilots, proof-of-concept programs, founder-led sales, or targeted outreach.
6. Why is Salesforce the right channel? Connect your product to Salesforce data, workflows, users, APIs, or customer needs.

Avoid generic statements such as “the total addressable market is every Salesforce customer.” A more credible plan identifies a specific starting segment and explains how the product will expand from there.

Pricing does not need to be final in every detail, but it should be internally consistent. Your listing language, sales proposal, customer contract, billing process, and Salesforce distribution model should not describe materially different commercial arrangements.

Salesforce’s partner program information explains that commercial arrangements vary according to partner type and distribution model. Use the current Partner Console and partner agreement materials as the source of truth.

3. Document the customer support model

A product can be technically sound and still create customer risk if no one knows how support will work after installation.

Your support plan should identify:

1. Support channels, such as email, portal, chat, or case management.
2. Support hours, geographic coverage, and holiday coverage.
3. Initial response targets for urgent, normal, and low-priority issues.
4. The escalation path from frontline support to engineering or leadership.
5. Onboarding activities, including implementation guidance, training, and configuration.
6. Documentation, knowledge articles, release notes, and administrator references.
7. Incident handling, customer communications, and post-incident review.
8. The person or team responsible for customer success, renewals, and adoption.

Response targets do not need to imitate the support model of a large enterprise software company. They do need to be realistic and aligned with your staffing. If you promise 24-hour coverage but have one part-time founder handling support, the plan will appear disconnected from operations.

Be specific about what customers manage themselves and what requires your involvement. This is particularly important for integrations that depend on external APIs, credentials, middleware, data mappings, or customer-managed infrastructure.

4. Explain the product before explaining the technology

Salesforce reviewers need technical information, but the first explanation should be understandable to a business stakeholder.

Start with:

1. The customer workflow the solution improves.
2. The users who interact with the product.
3. The Salesforce clouds, objects, records, or processes involved.
4. The implementation requirements and customer responsibilities.
5. The major limitations or unsupported use cases.

Then provide technical detail covering the managed package, APIs, external services, authentication, data flows, permissions, deployment approach, and upgrade process.

For a managed package or native integration, prepare a clear architecture summary that shows:

• Where code runs.
• What data is read, created, updated, or transmitted.
• Which permissions are required.
• Which third-party services are involved.
• How credentials and secrets are handled.
• How customers configure and uninstall the solution.
• How the roadmap may affect current customers.

The Salesforce security review submission guidance is a useful reference for organizing technical materials. Business plan preparation should complement, not replace, the security documentation.

Contact Our Team if you need a second review of your package architecture, integration boundaries, or data-access explanation.

5. Be realistic about traction

No installs or existing customers is not automatically disqualifying. A product may be early in its commercial development while still having a credible plan for validation and support.

The distinction is between limited traction and unsupported claims.

If you are pre-revenue, explain:

1. Which customer segment you will validate first.
2. How you will recruit design partners or pilot users.
3. What success criteria will determine product-market fit.
4. How feedback will influence the roadmap.
5. How early adopters will receive implementation and support.
6. What evidence you plan to collect before expanding the sales motion.

Do not inflate your pipeline, fabricate references, or imply that a pilot is a paying deployment when it is not. A transparent statement about product stage is more credible than a series of vague claims about demand.

Your plan should show that you understand the responsibilities of serving Salesforce customers even if your first customers have not yet arrived.

6. Use Salesforce ecosystem contacts effectively

The Salesforce ecosystem includes several contacts and resources, but each serves a different purpose.

1. Business Development Representative or partner onboarding contact: Helps clarify entry requirements, partner application steps, and initial business-process questions.
2. Technical Evangelist or technical enablement contact: Helps ISVs understand platform architecture, technical patterns, and preparation for technical review.
3. Partner Community and Partner Console: Provide access to onboarding information, listing tools, cases, documentation, and submission workflows.
4. Partner Account Manager: May support go-to-market alignment, ecosystem engagement, and growth once the relationship and partner stage justify that involvement.

Do not assume that every small ISV automatically receives a dedicated Partner Account Manager from the beginning. A PAM may also not be the person who resolves every business plan or security question.

Use the correct channel for each issue, keep written records of guidance, and verify that advice applies to your current solution type and distribution model.

7. Treat AgentExchange listing as a credibility decision

AgentExchange is more than a distribution channel. For many enterprise buyers, an AgentExchange listing and completed security review form part of vendor qualification.

Procurement, security, legal, and Salesforce administration teams may ask:

1. Is the application officially listed?
2. Has Salesforce reviewed the solution?
3. What data does the product access?
4. Who supports the application?
5. How long has the vendor operated?
6. What happens if the customer needs to uninstall, migrate, or escalate?

That does not mean every ISV should pursue a listing immediately. Consider whether your target market values AgentExchange presence enough to justify the time, preparation, commercial obligations, and potential review costs.

For a product sold primarily through Salesforce customers, partners, or enterprise procurement teams, the credibility value may be significant. For a narrowly scoped integration sold through an existing channel, another distribution approach may be appropriate.

8. Build a pre-submission checklist with owners

A practical checklist turns the BPR from a writing exercise into an operating-readiness review.

Item	Evidence to prepare	Common gap
Business plan	Completed answers covering company, product, market, pricing, GTM, and support	Generic positioning without a defined customer profile
Financial and pricing model	Pricing sheets, revenue assumptions, billing workflow, and distribution model	Listing price does not match sales or contract terms
Support model	Support channels, response targets, escalation map, and ownership	No named owner for customer success
Product documentation	Architecture summary, implementation guide, admin guide, and limitations	Technical detail exists, but business impact is unclear
Data and permissions	Object-level data map, permission set explanation, API and external-service inventory	Data access is described incompletely
Security materials	Test results, remediation records, secure development evidence, and review responses	Security work begins after business submission
Demo environment	Stable demo org, test credentials, sample data, and repeatable walkthrough	Reviewers cannot reproduce the primary use case
Legal and distribution	Partner agreement requirements, terms, privacy materials, and commercial documentation	Legal and finance owners are not involved early
Internal ownership	Named executive, product, engineering, sales, support, and legal owners	One founder is expected to answer every question

Assign an owner and target date to each item. If a document is not ready, record the reason and the next action rather than marking it complete.

9. Decide how CloudStreet can help

We help Salesforce technology companies and Salesforce customers prepare for the operational and technical realities of the platform.

For an ISV preparing for business plan or security review, our support can include:

1. Salesforce architecture and solution review.
2. Managed-package and integration readiness assessment.
3. Documentation of Salesforce data access, permissions, and integration dependencies.
4. Implementation, onboarding, and customer support model design.
5. Business-case and Salesforce-channel positioning.
6. Preparation of technical documentation and security-review materials.
7. Identification of gaps before submission to Salesforce.

We do not guarantee approval, and we do not replace Salesforce’s business, legal, or security review teams. Our role is to help you present a clear, technically defensible, and operationally credible application.

Our Salesforce Services team can also help organizations evaluate integration, implementation, managed support, and custom development requirements. If your product supports commerce or B2B workflows, our B2B Commerce Accelerator provides additional context on how we approach Salesforce-based customer experiences. For solutions involving automation or AI, see our Salesforce AI services.

Conclusion: Prepare the business behind the app

The AgentExchange security review evaluates important technical and security controls, but the AgentExchange business plan review examines whether the company behind the application has a coherent way to sell, implement, support, and improve it.

An ISV does not necessarily need a long customer list or a high install count. It does need a credible explanation of the problem, customer, pricing, operating model, support ownership, product architecture, and path to validation.

Treat the BPR as an opportunity to align your business plan with your product reality before you submit. As Salesforce processes, requirements, review sequences, and commercial models change, confirm the latest guidance through Partner Community, Partner Console, and your Salesforce contacts.

4 official Salesforce references to review

1. Salesforce Partner Program
2. How the Salesforce security review works
3. How to submit a solution for security review
4. AppExchange, now called AgentExchange, ISV Partner Onboarding Guide

Bookmark this guide and revisit it as your product, support model, and Salesforce partner journey develop. If you would like help preparing your business plan, architecture, or security-review materials, Get a Quote from CloudStreet or Contact Our Team. We are based in Houston, Texas, and support Salesforce customers and technology companies locally, nationally, and globally.