Building a Salesforce app for marketplace distribution is different from building a feature inside one Salesforce org. The product has to install in customer environments you don’t control, respect each org’s security model, survive upgrades, work within platform limits, and pass Salesforce’s review before public distribution. That makes Salesforce AppExchange app development a product engineering job as much as a Salesforce development job. Packaging decisions affect future releases. Permissions affect security review. Integration choices affect the review scope. Documentation affects both approval and customer installation. The marketplace itself also changed in 2026. Salesforce unified AppExchange, its earlier AgentExchange experience, and Slack Marketplace into the new AgentExchange in April 2026. Salesforce states that existing AppExchange apps remain part of the marketplace. Its current Summer ’26 guidance for ISV partners explains the unified marketplace and updated partner direction, while traditional Salesforce apps continue to use familiar package and security concepts. This article therefore uses “AppExchange app” for the established app category and search intent, while referring to AgentExchange Partner Console where that is the name used in the current interface. A reliable build sequence is straightforward in principle: define the product boundary, design for many customer orgs, choose the package model, build with Salesforce security rules in mind, test the released package, complete the AppExchange security review, finish the AppExchange listing process, and prepare a release plan that works after customers have installed the app. The hard part is making those decisions early enough that packaging or security problems don’t appear close to launch.
TL;DR
Salesforce AppExchange app development works best when packaging and security are treated as design inputs from the first sprint.
• Define who will install the app, which Salesforce products it depends on, and which data it can access.
• For a publicly distributed Salesforce Platform app, evaluate a Salesforce managed package, especially managed 2GP, as the package model.
• Plan namespace, metadata ownership, permission sets, upgrade behavior, and package versions before release work begins.
• Treat Salesforce app packaging as part of the architecture rather than a final deployment task.
• Run security checks throughout development and prepare test users, documentation, credentials, package details, and external-system access before the AppExchange security review.
• Build the marketplace page while review work is in progress. Salesforce’s current workflow allows listing work and security review work to progress in parallel.
• Complete the AppExchange listing process with accurate product details, prerequisites, pricing, documentation, screenshots, support information, and the correct package version.
• Plan package updates before the first release because customer upgrades become part of the product lifecycle.
Understanding Salesforce AppExchange App Development
An AppExchange app is a Salesforce solution built for distribution beyond one controlled Salesforce environment. A customer installs the product into an org that may have its own objects, automation, profiles, permission sets, integrations, sharing rules, record volumes, and managed packages. That changes the assumptions a development team can make. Code that works in the original development org can fail after installation if it expects a particular profile, field, object state, permission, record volume, or external endpoint. Salesforce AppExchange app development therefore has to account for variation between subscriber orgs from the start. A related overview of Salesforce AppExchange app development services describes package planning, Apex, Lightning Web Components, integrations, testing, security preparation, listing work, and later releases as parts of the same product lifecycle. The useful lesson is structural: these activities affect one another, so delaying package or security decisions until development is finished creates avoidable rework.
How an AppExchange product differs from an internal Salesforce build
An internal Salesforce application usually has a known environment. The team knows which users exist, which licenses are available, which fields have been configured, and what connected systems are present. An AppExchange product has to make fewer assumptions. Installation must work across supported editions and configurations. Access must follow the subscriber’s permissions. Package upgrades must preserve customer data and settings. External connections need to work without exposing credentials or requiring unsafe setup. This distinction affects architecture from the first design document. The application is no longer only a collection of working features. It becomes an installable product with a package identity, release history, security boundary, installation experience, and support lifecycle.
Who needs to be involved
A serious AppExchange build usually needs several responsibilities covered, even when the team is small:
• Product ownership for scope, audience, pricing, and release decisions
• Salesforce architecture for metadata, package boundaries, permissions, and org compatibility
• Apex and Lightning engineering for application behavior
• QA for installation, regression, upgrade, and user-access testing
• Security ownership for code findings, integrations, secrets, and review evidence
• Documentation ownership for setup instructions and reviewer guidance
• Marketplace ownership for listing details and release coordination
The same person can cover more than one responsibility. What matters is that none of these areas becomes an afterthought.
AppExchange And AgentExchange: What Changed In 2026
Salesforce launched the new AgentExchange marketplace in April 2026. It combines traditional AppExchange apps, Slack solutions, AI agents, integrations, and related partner offerings in one marketplace. Existing AppExchange apps haven’t disappeared. They remain part of the current Salesforce marketplace experience. For teams already familiar with AppExchange terminology, the largest practical change is naming in current publishing material. Recent Salesforce documentation refers to the AgentExchange Partner Console, AgentExchange listings, and AgentExchange security review. Developer material can still contain AppExchange wording, especially where it discusses established package concepts. The technical job remains familiar for a packaged Salesforce app. Teams still create a distributable solution, connect it to the partner publishing environment, complete required security work, build the marketplace listing, associate the correct version, and publish after the required approvals. For SEO and reader clarity, this guide continues using Salesforce AppExchange app development when discussing the established development category. When an instruction refers to a current Salesforce screen or process, the newer AgentExchange name is used where appropriate.
Plan The App Before Writing Package Code
The strongest time to solve AppExchange problems is before package metadata becomes difficult to change. Product boundaries, package ownership, permissions, dependencies, integration behavior, and upgrade rules should be understood before the team starts committing large amounts of code. Salesforce AppExchange app development should begin with an installation question: what has to be true in a subscriber org for this product to work? That question exposes dependencies that feature-focused planning can miss.
Define the customer and product boundary
Start with the exact use case. Identify who installs the application, who configures it, and who uses it during normal work. Then document which Salesforce clouds, objects, APIs, licenses, features, and external services the app requires. A useful product boundary answers questions such as:
• Which metadata belongs inside the package?
• Which settings must remain customer-controlled?
• Does the app require Sales Cloud, Service Cloud, Experience Cloud, or another product?
• Which Salesforce editions are supported?
• Does the app create or store customer data?
• Does it send Salesforce data to another system?
• Which features require admin setup after installation?
• What happens when an optional dependency is absent?
This boundary later informs documentation, testing, security review, and listing prerequisites.
Design for subscriber org differences
Customer orgs rarely look like the development org. A field may be hidden. A user may lack access to an object. An automation can run after your package changes a record. Another managed package can use the same standard object differently. Architecture should therefore avoid depending on assumptions that aren’t part of the documented prerequisites. Permission behavior needs explicit testing. Trigger logic should handle bulk work. Queries and DML need to respect Salesforce limits. Components should handle missing access without exposing restricted data. Teams building custom logic can use the same engineering discipline found in broader Salesforce development services where Apex, Lightning components, automation, and application behavior are planned around platform constraints. In an AppExchange product, those constraints matter even more because the developer can’t control every subscriber environment after installation.
Decide how configuration will work
A packaged product often needs settings that vary by customer. Avoid solving every variation with custom code. Decide which values belong in package metadata, custom metadata types, custom settings, permission sets, or an admin configuration interface. Good configuration design helps upgrades because customers can keep their settings while package code changes. It also reduces the temptation to maintain separate code branches for individual subscribers. Document every setting that affects security or external data movement. Reviewers need to understand how the app behaves, and customers need to know what they are enabling.
Design The Security Model Before Development
Security should be part of the data model and application flow. Adding permission checks after features are complete often produces scattered fixes and unclear behavior. The app should define which users can read or change each type of data, which operations need elevated rights, and which actions should fail when a user lacks access. This becomes the foundation for permission sets and code-level enforcement.
Object and field access
Apex can execute in contexts where platform behavior alone doesn’t automatically enforce every object or field permission expected by the application. Developers need to account for CRUD and field-level security where user permissions should apply. Choose an enforcement pattern that matches the operation and current Salesforce guidance. Test both authorized users and users with deliberately restricted access. A security test that only uses a system administrator proves very little about real customer behavior.
Record-level sharing
Sharing also needs explicit design. Apex class sharing declarations affect record visibility, and inherited execution can behave differently depending on the caller. Decide where user sharing should apply and document any case where the app intentionally performs work beyond a user’s record access. Elevated behavior should have a clear business reason and a controlled entry point.
Injection and untrusted input
Dynamic SOQL, search input, URL parameters, external payloads, and configurable values can become attack paths when they are joined directly into executable statements. Use bind variables where possible. If a value can’t be bound, use allowlists for expected identifiers or values rather than relying on broad character removal. Validate input close to the boundary where it enters the application.
Secrets and authentication
Passwords, API keys, client secrets, and tokens should never be stored in Apex source or exposed through client-side JavaScript. Use Salesforce credential and authentication features that fit the integration. Keep scopes limited to what the app needs. Document token handling and revocation behavior. These decisions become important when the app includes outside systems because the AppExchange security review covers more than the code inside the package.
Build Apex, Lightning Components, And Automation For Distribution
Once the product boundary and security model are clear, development can move into normal sprint work. The difference is that every feature should be judged as packaged software rather than local customization. Salesforce AppExchange app development should maintain source control as the working record for code and metadata. Package releases should come from controlled source and repeatable build steps rather than manual edits made directly in a packaging environment.
Apex development
Apex should be tested for bulk behavior, governor limits, access control, error handling, and package upgrade effects. Trigger logic should avoid assumptions about execution order outside the boundaries Salesforce guarantees. Unit tests should verify behavior rather than exist only to reach coverage. Include negative cases, restricted users, high-volume operations, empty data sets, and dependency failures where they affect product behavior. Package promotion has its own coverage requirements for managed 2GP. Salesforce states that a beta managed 2GP version must meet a 75% Apex code coverage requirement before it can be promoted to managed-released status.
Lightning Web Components
Lightning Web Components should handle loading, empty results, permission errors, and server failures cleanly. Client-side code must not expose secrets or assume that hiding a control equals enforcing access. Authorization belongs at the server and data layers as well. A user who can’t see a button should also be unable to perform the restricted operation through another route. Use Salesforce design patterns where they help the product fit naturally into Lightning Experience. Keep client-side dependencies under review because third-party JavaScript can affect security findings and long-term maintenance.
Flow and declarative components
Flows, permission sets, custom metadata, layouts, tabs, record types, and other metadata can be part of the package. Each one should be tested after installation rather than only in the development environment. Pay attention to metadata dependencies. A component that quietly depends on an unpackaged object, field, or permission can make installation fail or leave the application partly configured.
Plan External Integrations As Part Of The Product
External systems expand the application boundary. Salesforce security review guidance can bring web services, REST APIs, mobile applications, browser extensions, and other connected components into review scope when they are part of the packaged solution. Map each integration before implementation. Define what data leaves Salesforce, what returns, how the user authorizes access, which system owns each record, and what the app does when the external service is unavailable. For products with substantial integration work, an architecture similar to established Salesforce API integration services can separate authentication, data mapping, error handling, and monitoring responsibilities before code is written. That separation makes review evidence easier to prepare because the team can explain each connection and its security boundary.
External Client Apps now matter for new integrations
This area changed recently. Salesforce guidance published in September 2026 says new integrations must use External Client Apps instead of Connected Apps. It also states that packaged Connected Apps or External Client Apps and the integrations used by the managed package fall within security review scope. The current Salesforce guidance for Connected Apps and External Client Apps explains the packaging and review expectations, so teams starting a new integration should confirm their authentication design against that guidance before submission. This is especially important for teams reusing an older AppExchange architecture. A design based on past Connected App guidance may need to be reconsidered for a new package or new integration.
Understand Salesforce App Packaging Before Release
Salesforce app packaging determines how the product is assembled, identified, installed, upgraded, and distributed. It isn’t simply a ZIP file around finished metadata. For a marketplace product, the package model affects version history, namespace behavior, component ownership, dependencies, subscriber upgrades, and what Salesforce can associate with the marketplace listing. A Salesforce managed package is the normal distribution model for a packaged commercial Salesforce application because it provides controlled versions and an upgrade path. Unmanaged packages can be useful for metadata sharing or other limited cases, though they don’t provide the same managed product lifecycle.
Managed package vs. unmanaged package
| Area | Managed Package | Unmanaged Package |
| Main use | Product distribution | Metadata sharing or customer-owned starting point |
| Upgrade path | Supports managed upgrades | No managed upgrade lifecycle |
| Publisher control | Package components follow managed rules | Subscriber receives editable metadata |
| Version management | Formal package versions | Limited release control |
| Marketplace product fit | Common choice for installable products | Usually unsuitable for a managed commercial product |
For teams building a listing intended for long-term customer installation, Salesforce app packaging needs to support what happens after version 1.0. That is why release and upgrade behavior should be part of package selection.
Understand Managed 2GP And Package Versions
Salesforce supports second-generation managed packaging, usually called managed 2GP. It uses a source-driven development model tied to a Dev Hub and Salesforce CLI workflows. Current Salesforce documentation provides a specific managed 2GP publishing path for the marketplace where released package versions become available after the Dev Hub is connected to the Partner Console. The package can then be registered, reviewed, and associated with the marketplace workflow. A Salesforce managed package using 2GP also has package ancestry. Ancestry helps Salesforce understand which released versions can upgrade to later versions. Teams should plan this before creating a long chain of releases because upgrade paths become customer-facing behavior.
Namespace planning
A namespace identifies packaged components and helps avoid naming collisions. Treat it as a durable product decision. Check naming carefully before the product gains customers, integrations, documentation, and external references tied to that namespace. The namespace also matters across package relationships. If the product will eventually contain more than one package, define package boundaries and dependencies before the architecture becomes difficult to separate.
Beta and managed-released versions
New managed 2GP versions begin as beta. Salesforce states that beta package versions can be installed only in scratch orgs and sandboxes. A beta installation can’t later be upgraded in place like a normal released customer version. A release candidate therefore needs to be tested thoroughly before promotion. Salesforce’s managed 2GP promotion guidance explains that promotion changes the package version to managed-released status and that this action can’t simply be reversed. After promotion, the version can be installed in production and distributed to customers. This makes Salesforce app packaging a release-control issue. Promotion should happen after installation testing, regression testing, access testing, and upgrade checks are complete.
Test The Package Like A Customer Will Install It
A package can work perfectly in the development org and fail when installed elsewhere. Package QA should therefore include clean-environment installation. Test in supported Salesforce environments that resemble real subscriber conditions. Avoid preparing the test org so heavily that hidden dependencies are never exposed. A useful package test covers:
• Fresh installation
• Required permission assignment
• Admin configuration
• Main user workflows
• Users with restricted access
• External authentication
• High-volume operations
• Upgrade from an earlier supported version
• Uninstall behavior where relevant
Teams already using formal Salesforce implementation services may recognize the value of separating configuration, testing, deployment, and user validation into controlled stages. For an AppExchange product, the same discipline needs an added package layer because installation itself is part of the product experience. Salesforce AppExchange app development should also test failure states. Disconnect an integration. Remove a permission. Use empty data. Reach realistic volume. Try an unsupported setup and confirm that the product fails with a useful message rather than an unhandled exception.
Prepare For The AppExchange Security Review During Development
The AppExchange security review is Salesforce’s assessment of the solution before qualifying packaged products can be publicly distributed through the marketplace. The review focuses on whether the app can expose customer data or introduce exploitable behavior. Treat review readiness as a repeated development activity. Waiting until the release candidate exists can turn common coding patterns into large remediation work. Salesforce states that managed packages and certain API solutions must pass security review for marketplace distribution. The process includes automated checks and human security work, with the exact scope affected by the solution architecture.
What reviewers can examine
For a packaged Salesforce application, review work can include areas such as:
• Object and field permissions
• Record-sharing behavior
• Apex execution context
• Injection risks
• Cross-site scripting risks
• Authentication and authorization
• Secrets and credential storage
• External endpoints
• Transport security
• Third-party JavaScript
• Connected external components
• Reviewer documentation and test access
The exact set depends on the application. A package that stays entirely on Salesforce has a different review boundary from a package that exchanges data with an external SaaS platform.
Common causes of review problems
Many review findings start with ordinary engineering shortcuts. A dynamic SOQL query may trust user input. An Apex method may return fields without checking user access. An integration may use credentials stored in an unsafe place. A custom endpoint may accept actions without enough authorization checks. Documentation can cause delays too. If reviewers can’t reach a feature, don’t have required credentials, or can’t understand an external dependency, they may be unable to test the application properly. The best defense is repeatability. Every security finding should be treated as a pattern to search for across the whole codebase instead of as one isolated line to patch.
Use The Current Salesforce Code Analyzer
Static analysis should run before the package reaches Salesforce. As of September 2026, Salesforce Code Analyzer v5 is current, and Salesforce states that v4 was retired in August 2025. The current Salesforce Code Analyzer documentation describes support through Salesforce CLI, VS Code, GitHub Actions, and DevOps Center testing. Its engines cover areas including Apex, JavaScript, Lightning Web Components, Flows, duplicate code, dependency risks, and Salesforce-specific security rules, so teams can make scanning part of normal development rather than a one-time pre-submission event. For Salesforce AppExchange app development, run the scanner during development and again against the release candidate. Keep findings in the engineering workflow so security issues don’t accumulate until submission. Static analysis isn’t a guarantee that an application will pass review. It catches classes of problems. Manual testing and architecture review are still needed for behavior that a scanner can’t fully understand.
Build A Security Review Submission Package
A clean submission helps reviewers reproduce the application correctly. Salesforce asks partners to provide the environments and information needed to exercise the product. Prepare the materials while development is still active. The AppExchange security review should never be the first time someone outside the build team tries to follow the setup instructions.
Reviewer access
Create the required test environment and verify credentials before submission. The reviewer needs to reach all relevant areas of the product. If different roles expose different behavior, provide users that allow those paths to be tested. Include sample data when a feature can’t be exercised without it.
Installation and configuration instructions
Write setup instructions from a fresh-install point of view. Include package prerequisites, permission assignment, authentication steps, external-system setup, and any configuration needed before the first workflow can run. Have someone outside the core development group follow the document exactly. Any question they have is a likely reviewer question.
External-system information
If the solution calls an external service, include enough detail for the reviewer to understand and test that part of the architecture. Explain what data crosses the boundary and how authentication works. Provide the required test access. This is where integration documentation and the AppExchange security review meet. Missing external access can stall a review even when the Salesforce package itself is working.
Submit The AppExchange Security Review
The review starts from the solution area in the current Partner Console. Salesforce’s current publishing material instructs partners to connect the technology, choose the solution, start the review, and work through the review wizard. The current Security Review submission guide also states that listing approval work and security review work can happen in parallel. That means the team doesn’t need to leave all marketplace content until after the package enters review. Before pressing submit, recheck:
• The correct managed package version is selected.
• Test credentials work.
• All required external systems are available.
• Installation instructions match the submitted build.
• Scanner findings have been reviewed.
• Security questions are answered accurately.
• Every feature in scope can be reached by the reviewer.
Salesforce’s current guidance varies by page. One publishing module says to allow 2 to 4 weeks, while the detailed security-review module says a solution typically takes 4 to 5 weeks. Plan for several weeks and check the current Partner Console guidance before setting a launch date. If a review returns findings, address the underlying pattern. Re-run tests and scans before submitting again. The goal is to prevent the same weakness from appearing elsewhere in the package.
Build The AppExchange Listing While Review Is Underway
The AppExchange listing process is the customer-facing side of publishing. It explains what the app does, who it is for, what it requires, how customers get it, and where they can find support. Salesforce AppExchange app development teams sometimes treat listing work as marketing work that begins after engineering. That creates late questions about editions, prerequisites, installation behavior, or package versions. Listing fields are also technical declarations, so product and engineering should review them.
Describe the application accurately
The listing should tell a buyer what problem the product handles and what must be present in the Salesforce org. Avoid broad claims that aren’t supported by the released package. Include prerequisites clearly. If the app depends on a particular Salesforce product, edition, feature, license, or external account, make that visible before installation.
Use screenshots that explain the product
Screenshots should help a reader understand actual workflows. Prefer product screens that demonstrate how users perform meaningful tasks. Keep screenshot content consistent with the released version. An image that shows a feature absent from the linked package creates confusion and can increase support work.
Explain pricing and access
State whether the app is free, paid, subscription-based, or uses another supported pricing arrangement. Explain any account, external subscription, or license requirement that affects use after installation. Pricing details should agree with what customers encounter after they select the marketplace action.
Complete The AppExchange Listing Process In Partner Console
In Partner Console, connect the solution, open Listing Builder, select the correct released package version, complete the required approval checks, and publish once the required approvals are in place. Salesforce’s current Listing Builder guidance explains how partners link the connected managed package solution and select its version. The listing can be prepared while security review is in progress, though publication still depends on the required approvals.
Design The Installation Experience
Installation is the customer’s first real interaction with the product. A clean listing can’t compensate for a confusing setup. Keep the required steps as small as the application allows. Use permission sets to make access understandable. Provide a clear place for configuration. Detect missing prerequisites where possible and explain them in plain language. Integration-heavy apps need additional care. Teams working across APIs and middleware can use patterns similar to those described in Salesforce integration services where system ownership, authentication, data movement, and failure handling are defined before deployment. For a packaged app, these decisions should be translated into admin setup instructions that work in subscriber orgs. Test the documentation against the same released Salesforce managed package that will be linked to the listing. Small differences between an internal build and the released package can produce setup instructions that no longer match customer screens.
Plan Versioning Before The First Public Release
The first package release starts a history that future releases have to respect. That is why Salesforce app packaging and version policy belong in product planning. Define what your team considers a major version, a minor version, and a patch. Decide how release branches work and which supported customer versions can upgrade to each future package version. With managed 2GP, package ancestry influences upgrade paths. Salesforce requires ancestry information once promoted versions exist, and its developer documentation describes how released versions become ancestors for later versions. A Salesforce managed package should therefore have a version policy that engineering, QA, support, and documentation teams understand.
Test upgrades as separate release events
An upgrade is different from a fresh installation. Existing records, settings, permissions, and customer configuration are already present. Test a real supported earlier version, create representative data, apply the new package, and rerun the main workflows. Verify that settings survive and that new required steps are documented. Don’t assume a passing fresh install proves a safe upgrade.
Maintain The App After Marketplace Launch
Salesforce AppExchange app development continues after publication. Salesforce platform releases continue, customer orgs change, dependencies evolve, and security issues can appear in package code or third-party components. Maintenance should include regression testing against upcoming Salesforce releases, package dependency checks, security scanning, integration checks, documentation updates, and controlled package releases. A product with an established customer base also needs clear ownership for defects and release communication. Related Salesforce support services illustrate how issue resolution, platform changes, security checks, and application maintenance can be treated as continuing responsibilities after deployment. For an AppExchange product, that operational ownership should connect directly to package version planning. New package versions don’t automatically require the same full review path as an initial product submission in every case. Salesforce provides mechanisms for later versions and listing updates, though material changes still need to follow current marketplace security rules. Teams should check current Partner Console instructions before each release rather than assuming an older process still applies.
Common AppExchange Development Mistakes
| Mistake | Consequence | Correction |
| Choosing the package model too late | Dependencies and namespace problems surface close to release. | Decide the package model during architecture planning. |
| Testing only as an administrator | Permission failures remain hidden until customer testing or review. | Include restricted users and intentional permission gaps in QA. |
| Hardcoding subscriber assumptions | The package can fail in orgs that don’t match the development environment. | Keep customer-specific values in documented configuration. |
| Ignoring integration scope | External services can add unplanned security-review work. | Include connected systems in review planning from the start. |
| Writing installation docs from memory | Setup instructions can omit steps that seem obvious to the build team. | Have someone outside the build team perform a fresh install using only the published instructions. |
| Treating the listing as separate from engineering | Prerequisites, package version, or install details can disagree with the released product. | Have engineering verify the technical listing fields before publication. |
A Practical AppExchange Build Sequence
A dependable sequence keeps architecture, packaging, security, and marketplace work connected.
| Phase | Main Work | Exit Condition |
| Product definition | Audience, use case, prerequisites | Product boundary approved |
| Architecture | Data model, access, configuration, dependencies | Package-ready design |
| Development | Apex, components, automation, integrations | Main workflows working |
| Packaging | Namespace, managed package, versions | Installable release candidate |
| QA | Fresh install, access, volume, integration, upgrade tests | Release defects closed |
| Security preparation | Code scans, manual checks, reviewer materials | Submission package ready |
| Security review | Submit and address findings | Required approval received |
| Listing | Product details, pricing, media, docs, linked version | Listing approved |
| Release | Publish and monitor | Customer installation available |
| Maintenance | Fixes, upgrades, platform checks | Ongoing release cycle |
This sequence doesn’t mean every phase waits for the previous one to finish. Listing content can be drafted while the AppExchange security review is running. Security scanning should start during development. Upgrade planning should begin during Salesforce app packaging. Teams that need architecture guidance across these areas can also review broader Salesforce consulting services covering custom development, package work, security preparation, and post-launch maintenance. The relevant point for an AppExchange team is that architecture decisions need an owner who can see how development choices affect later review and release work.
How To Know The App Is Ready To Submit
A release candidate is ready when the team can reproduce the customer journey without relying on development-org knowledge. Use a final release gate covering product behavior, package state, security, and marketplace materials. Package readiness
• The correct version is managed-released where required.
• Installation succeeds in clean supported environments.
• Upgrade behavior has been tested where an earlier version exists.
• Package dependencies are documented.
• Namespace and version details are final.
Security readiness
• Access is tested with restricted users.
• CRUD, FLS, and sharing behavior are reviewed.
• Dynamic queries and untrusted input paths are checked.
• Secrets aren’t stored in source or client code.
• External authentication follows current Salesforce guidance.
• Current Code Analyzer findings have been assessed.
• Reviewer credentials and environments work.
Listing readiness
• Product description matches the released build.
• Prerequisites and supported environments are correct.
• Screenshots match the current product.
• Setup documentation has been tested from a clean install.
• Support information is current.
• Pricing details are accurate.
• The correct package version is ready to link.
If these checks are repeatable, Salesforce AppExchange app development has moved from a working project to a release-ready product.
Conclusion
Building an AppExchange app requires more than writing Apex or Lightning components. The product has to survive installation in customer orgs, respect Salesforce security controls, support future package versions, and give reviewers enough information to test the whole solution. The most reliable approach connects architecture with Salesforce app packaging from the start. A Salesforce managed package then becomes part of the release model instead of a container added at the end. Security checks run during development, and the AppExchange security review becomes a planned release gate rather than an emergency before launch. The AppExchange listing process should run alongside technical release work because package versions, prerequisites, installation details, documentation, and marketplace content need to describe the same product. Salesforce’s 2026 move to AgentExchange changes marketplace terminology and parts of the publishing experience, though the core engineering requirements for packaged Salesforce applications remain familiar. Salesforce AppExchange app development still comes down to disciplined architecture, controlled releases, secure code, clear setup, and reliable upgrades.
FAQs
What is Salesforce AppExchange app development?
Salesforce AppExchange app development is the process of building a Salesforce application for distribution through Salesforce’s marketplace. It includes product design, Apex or Lightning development, permission design, testing, Salesforce app packaging, security preparation, listing work, release management, and later package updates. Since Salesforce unified its marketplaces into AgentExchange in 2026, current publishing screens can use AgentExchange terminology even when teams still refer to traditional Salesforce products as AppExchange apps.
What is an AppExchange security review?
The AppExchange security review is Salesforce’s security assessment for qualifying marketplace solutions. Review scope can include packaged code, permissions, data access, authentication, external endpoints, third-party components, and supporting systems connected to the application. Salesforce also needs working test access and enough documentation to exercise the solution.
How long does the AppExchange security review take?
Salesforce’s current publishing Trailhead tells partners to allow about 2 to 4 weeks for security review. Actual timing can vary with solution architecture, submission quality, reviewer demand, and whether fixes are required. Teams should avoid setting a public launch date that assumes the first submission will complete without questions or remediation.
What is a Salesforce managed package?
A Salesforce managed package is a package type intended for controlled distribution and versioned upgrades. It lets a publisher release package versions while keeping package components under managed rules. For a marketplace product expected to receive later releases, managed packaging provides the release structure that unmanaged metadata sharing doesn’t provide.
Should a new AppExchange app use managed 2GP?
Managed 2GP is an important option for new Salesforce package development and has a current Salesforce publishing path tied to Dev Hub, Salesforce CLI, package versions, and Partner Console. The right choice still depends on product history and existing package requirements. Teams with an established 1GP product should assess migration separately instead of assuming the same path as a new application.
What is Salesforce app packaging?
Salesforce app packaging is the process of organizing Salesforce metadata into a distributable package with a defined identity and version history. It covers package type, namespace, metadata ownership, dependencies, version numbers, release status, upgrade paths, and installation behavior. Those choices affect both security review and future customer upgrades.
Can an unmanaged package be used for a public AppExchange product?
Unmanaged packages can distribute metadata, though they don’t provide the managed version and upgrade model expected for many marketplace products. Public packaged solutions that need publisher-controlled releases generally use managed packaging. Teams should confirm the current listing and review requirements for their exact solution type before finalizing package architecture.
What does the AppExchange listing process include?
The AppExchange listing process covers the marketplace information customers use before installing or buying the product. It includes the product summary, prerequisites, pricing, screenshots, documentation, support information, installation method, and linked solution version. The listing should describe the actual released package rather than a future or internal build.
Can the listing be prepared while security review is running?
Yes. Current Salesforce publishing guidance allows listing approval work and security review work to proceed in parallel. The package still needs the required security status before publication where review is mandatory, though preparing the listing at the same time can prevent marketplace content from becoming the next delay after technical approval.
Do package updates require another full security review?
Salesforce doesn’t require a full initial-style review for every ordinary package update. Current publishing guidance provides an update and attestation path for later approved package versions. Material changes still need to comply with current security requirements, so release teams should check the Partner Console and current Salesforce documentation before linking a new version.
What should be tested before publishing an AppExchange app?
Test fresh installation, permissions, normal user workflows, restricted users, integrations, Salesforce limits, package upgrades, and failure conditions. Verify the exact managed-released build rather than relying only on the source version used during development. Setup documentation should also be tested from a clean environment.
How should external integrations be handled in an AppExchange app?
Treat every external integration as part of the application’s security boundary. Document data movement and authentication, protect credentials, limit permissions, test failure behavior, and include external systems in security preparation. For new integrations, Salesforce’s September 2026 guidance says teams should use External Client Apps rather than create new Connected Apps.
Why should package versioning be planned before launch?
Customers install specific package versions, and future releases must provide a safe upgrade path from those versions. Version policy affects ancestry, regression testing, documentation, support, and release communication. Planning this during Salesforce AppExchange app development prevents version history from becoming an accidental collection of releases that are difficult to maintain.
What is the biggest mistake teams make when building an AppExchange app?
A common mistake is treating packaging and security as tasks that start after feature development. By that stage, namespace choices, access patterns, external integrations, and metadata dependencies may already be deeply embedded in the product. Planning those areas before development gives the team a much cleaner route through packaging, review, listing, and later releases.
