Salesforce customers download bi-directional sync apps from AgentExchange, the Salesforce marketplace that now includes what was AppExchange. A sync shipped as a managed package installs from its listing in a few clicks. A sync that runs in the vendor's own cloud has an API listing, and Get It Now sends the customer to the vendor's site to connect it. Outside the marketplace, customers use a vendor's install link, a consulting partner's build, or an open source package they maintain alone.
This guide is for SaaS founders, CTOs and product leaders whose enterprise customers keep asking where to install your two-way Salesforce sync. Treat the answer as a product decision, not a marketing one. It fixes your listing type, which Salesforce won't let you change later. It also decides what the customer's admin approves during install and how every fix reaches their org. You build the package, pass security review, publish the listing, then support every installed org. Appnigma helps with that route. Our marketplace apps service puts "Your product, inside Salesforce or HubSpot." It covers the native app, listing preparation and review support. If you are an admin comparing sync tools for your own org, our list of Salesforce two-way sync platforms fits that question better.
Updated October 2026. Checked against the Salesforce AgentExchange install guide, the ISVforce listing and security review docs, and the Salesforce limits reference. The earlier version ended the install steps at Get It Now and said listed apps are safer because of security review. It also claimed managed apps "scale effortlessly." This update corrects those points. It adds the AgentExchange name, the two listing types a sync can use, and what an installed sync costs the customer's org.
Four places customers get a Salesforce two-way sync
The route a customer uses sets who installs the sync, who upgrades it, and whether Salesforce reviewed it. Most vendors with a packaged sync end up offering two routes at once, a listing for discovery and a direct install URL for onboarding.
| Route | What the customer installs | How fixes reach them | Security review |
|---|---|---|---|
| AgentExchange, packaged solution | A managed package, from the listing | Push upgrades, or a newer version the admin installs | Required before listing |
| AgentExchange, API listing | Nothing in Salesforce, the customer connects from the vendor's site | The vendor deploys in its own cloud | Required before listing |
| Vendor install link or in-product connector | A package version URL, or an OAuth connection started in the vendor's app | Same as the two rows above, without a listing | Not required unless listed |
| Consulting partner or open source | Custom code or an unmanaged package | The customer's own team | None |
Enterprise admins usually check the marketplace first, because a listing puts the publisher, supported editions and the reviewed version on one page. Salesforce calls AgentExchange a unified marketplace for apps, agents and consulting services. Its install guide says "we've unified AppExchange, AgentExchange, and Slack Marketplace into a single destination." Customers who search for the old AppExchange name land in the same place.
The vendor link route is real too. For a second-generation managed package, Salesforce says "anyone with the URL and a valid login to a Salesforce org can install the package," per Use a URL to Install a Second-Generation Managed Package. Installs from that URL still show up in your Marketplace Analytics, so a listing and a direct link don't split your install data.
The last row is the one to steer customers away from. Unmanaged packages leave the publisher with "no control over the installed components," and the publisher "can't change or upgrade them." A two-way sync that cannot be upgraded breaks the first time either side changes an API.
Which listing type fits your two-way sync
Salesforce offers three listing types, which are packaged solution, API and consultant listings. You "can't change the listing type after it's created." A sync product fits one of the first two, and the choice follows where the sync code runs.
Pick a packaged solution when the sync needs something inside the customer's org. That might be custom fields to hold your record IDs, or a flow that reacts to edits. It might be a Lightning component that shows sync status on the record. Pick an API listing when the sync lives entirely in your cloud and talks to Salesforce over its APIs. Salesforce defines that type as "a solution that interacts with the Salesforce Platform by using REST API, SOAP API, or other Platform APIs," per AgentExchange Solution Types.
The two types install differently. Salesforce's installation methods page says "API solutions can't be installed directly from AgentExchange." With the website method, customers who click Get It Now "are directed to your website to complete the installation process." A managed package listing lets customers install "in their Salesforce sandbox or production environment through the AgentExchange installation sequence without your assistance."
Many two-way syncs end up as a package even when most logic runs in the vendor's cloud. The reason is Change Data Capture (CDC), the Salesforce feature that publishes an event for each record change. Salesforce's Change Data Capture Allocations page says "the maximum number of entity selections of 5 applies to selections that you make, or selections that an unmanaged or managed package makes, except for AppExchange released managed packages." A sync that subscribes to change events from outside a package has to share those five object selections with every other integration the customer runs. The exemption covers object selections only. Delivered events still count toward the org's daily delivery allocation, 25,000 on Enterprise Edition per the same page.
Our guide to the three AgentExchange listing types covers the full table. Our marketplace guide explains how to list an integration that runs outside Salesforce.
What the customer's admin sees after clicking Get It Now
The install flow is where enterprise deals stall, so read it from the admin's side. Installing needs the "Download AgentExchange Packages" permission. It works in Group Edition and every edition above it, plus Developer Edition, per Installing Packages. After Get It Now, the admin chooses a production environment, agrees to terms and clicks Confirm and Install.
Sandbox testing takes a different button. The same guide says "Get It Now supports package installation in production environments only. To install a package in a sandbox environment, select the Try It option." Put that sentence in your install docs, because security teams at larger customers insist on a sandbox install first.
Two later screens decide whether the install goes through. The admin is asked to "review the API access that package components have been granted," and can cancel there. The admin then picks one of three security options, which are Install for Admins Only, Install for All Users, and Install for Specific Profiles. Ship a permission set for your integration user and write "choose Admins Only, then assign our permission set" in the install docs. That passes the customer's internal review faster than a request for All Users.
Marketplace Analytics record this funnel for you. A Get It Now click and an install are separate metrics. Installs include those "initiated on AgentExchange, your website, or from a code repository." A wide gap between clicks and installs usually points at the permission screen or a missing edition, not at the listing copy.
Does a marketplace listing mean a sync app is safe?
A listing means the app passed Salesforce's security review, not that Salesforce vouches for it. Managed packages and Salesforce Platform API solutions "must pass our security review" before they are listed, per Pass the AgentExchange Security Review. The same page says "Salesforce makes no guarantees regarding the quality or security of any Partner Application," and that customers are responsible for evaluating it.
For a SaaS vendor, that cuts both ways. The review is a gate you clear before customers can find you, and the four-stage process runs from Prepare and Submit through Submission Verification and Testing to Done. Passing once doesn't end it. Salesforce runs periodic security re-reviews and says "if your solution shows significant change, it's likely that we require a re-review." Upgrading a reviewed managed package version doesn't repeat the full review. The same page notes that a voluntary re-review lets you "show a more recent reviewed version and date" on your listing. A customer's security team reads that date. A sync whose last review predates two years of releases invites harder questions than one reviewed this year.
The review also doesn't replace your customer's own vendor security questionnaire. Expect both, and keep the review report and a data flow diagram ready. Our page on what the Salesforce security review checks covers the submission itself.
What an installed sync costs the customer's Salesforce org
The listing hides a cost the customer's admin will find in the API usage report. A sync spends the customer's allocation, not yours. An Enterprise Edition org gets a base of 100,000 API calls per 24 hours. Each Salesforce license adds 1,000 more, per API Request Limits and Allocations, and purchased add-ons raise it further.
Here is a worked example from those documented numbers. A customer with 50 Salesforce licenses on Enterprise Edition has 150,000 calls a day. If your sync writes 15,000 changed records a day with one REST call each, it uses 10% of that org's allocation before any of the customer's other tools run. The same page caps long-running requests, those lasting 20 seconds or more, at 25 at once in production orgs. A sync that runs large queries in parallel can hit that ceiling at a customer who already runs a data warehouse connector.
Polling makes this worse, which is why event-based sync is the better default. Change Data Capture exists to "update data in an external system instead of doing periodic exports and imports of data or repeated API calls." It is available in Enterprise, Performance, Unlimited and Developer editions, per the Change Data Capture overview. A sync that also sells to Professional Edition customers needs a polling fallback. Our guide on how to build two-way sync across customer orgs covers the event design.
How fixes reach every org that installed your sync
Two-way sync breaks more often than one-way sync, because both sides change. How a fix reaches each customer depends on the route. An API listing deploys in your cloud, once. A managed package needs each org upgraded, and push upgrades do that "without asking customers to install the upgrade themselves."
Push upgrades have conditions. Salesforce says "you can push upgrades to packages that have passed AgentExchange security review only," and you enable the feature by logging a case with Partner Support. Plan for that before your first customer installs, not after the first bug. Without push upgrades, every customer's admin has to install the new version by hand, and some won't. Our managed package guide walks through push upgrades and install links.
Mistakes SaaS teams make when shipping a sync app
These show up after launch, when the first enterprise customers install.
- Choosing the API listing type, then finding out the sync needs fields or a change event channel in the customer's org. The listing type can't be changed.
- Writing install docs that start at Get It Now and never mention Try It for the sandbox install.
- Asking for Install for All Users when the sync only needs an integration user.
- Leaving supported editions vague. Change Data Capture isn't available in Professional Edition, so say which editions get event-based sync.
- Planning OAuth around a new connected app. Salesforce's packaging docs say connected apps creation is restricted as of Spring '26, so new syncs start with an External Client App.
- Shipping without push upgrades enabled, so a sync fix sits uninstalled in half your customer orgs.
If you're still deciding whether to build the sync at all, our guide on whether to build or buy the sync covers that choice.
Frequently Asked Questions
Is AppExchange now called AgentExchange?
Yes. Salesforce's install guide says it unified AppExchange, AgentExchange and Slack Marketplace into one destination called AgentExchange. Older docs and many listings still say AppExchange.
Can customers install a two-way sync app in a sandbox first?
Yes. Get It Now installs to production only, so the admin clicks Try It on the listing to install in a sandbox.
Can an API-only sync be installed from AgentExchange?
No. Salesforce says API solutions can't be installed directly from the marketplace. Get It Now sends the customer to your website, or tells them you'll be in touch.
Can Appnigma build and list a two-way sync app for our product?
Yes. Through marketplace apps, Appnigma builds the managed package, prepares the listing and supports the security review. Salesforce controls review timing, and maintenance runs on a separate retainer.
Related Articles
- What Is Salesforce AppExchange
- What Is Salesforce AgentExchange
- Salesforce App Marketplace Guide
- Salesforce Security Review Guide
- Best Way to Do Bidirectional Data Synchronization in Salesforce
- Build vs Buy Bidirectional Sync
Sources
- Salesforce Developers, AgentExchange Install Guide, What Is AgentExchange?
- Salesforce Developers, AgentExchange Install Guide, Installing Packages
- Salesforce Developers, Second-Generation Managed Packaging Developer Guide, Use a URL to Install a Second-Generation Managed Package
- Salesforce Developers, First-Generation Managed Packaging Developer Guide, Developing and Distributing Unmanaged Packages
- Salesforce Developers, ISVforce Guide, Select an AgentExchange Listing Type
- Salesforce Developers, ISVforce Guide, AgentExchange Solution Types
- Salesforce Developers, ISVforce Guide, Installation Methods for AgentExchange Solutions
- Salesforce Developers, Change Data Capture Developer Guide, Change Data Capture Allocations
- Salesforce Developers, ISVforce Guide, Customer Engagement in AgentExchange Marketplace Analytics
- Salesforce Developers, ISVforce Guide, Pass the AgentExchange Security Review
- Salesforce Developers, ISVforce Guide, AgentExchange Security Review Stages
- Salesforce Developers, ISVforce Guide, Periodic Security Re-Reviews on AgentExchange
- Salesforce Developers, Salesforce Developer Limits and Allocations Quick Reference, API Request Limits and Allocations
- Salesforce Developers, Change Data Capture Developer Guide, Keep Your External Data Current with Change Data Capture
- Salesforce Developers, Change Data Capture Developer Guide, Change Data Capture
- Salesforce Developers, Second-Generation Managed Packaging Developer Guide, Push a Package Upgrade for Second-Generation Managed Packages
- Salesforce Developers, First-Generation Managed Packaging Developer Guide, Connected Apps
