Evaluate an AgentExchange (formerly AppExchange) app the way you would evaluate any vendor that touches customer data. Confirm a third-party app beats a native feature or a small build. Find out where your data goes and what access the app requests. Measure what it costs your org in limits and automation. Then prove it in a sandbox and write the exit plan before you sign. A listing badge and good reviews are a starting point, not an approval.
Should you buy an app at all, or use what Salesforce already has?
Check native features first, then a small build, then the marketplace. An app earns its place when it solves a problem that is costly to maintain yourself and common enough that a vendor keeps improving it.
Document generation, e-signature, enrichment, scheduling and backup are typical buys because they need ongoing engineering you do not want to own. A single custom screen or a niche approval rule usually is not. Our guide on customization versus configuration sets out how to weigh a build against what the platform already does.
- Buy when the capability is outside your team's skills and changes often, such as e-signature compliance or data feeds.
- Build when the logic is specific to how you work and small enough to document and support.
- Use native features when they meet most of the need, even if the vendor demo looks more polished.
What does Salesforce's security review actually guarantee?
It shows the app met Salesforce's security requirements when it was reviewed. It does not certify the vendor's ongoing practices, and Salesforce says customers remain responsible for evaluating an app's quality, security and function.
Salesforce's partner documentation describes the review as a test of how a partner solution protects customer data and resists common attacks. Apps can also be re-reviewed periodically. Salesforce has been renaming the marketplace AgentExchange, so you may see either name in its documentation and on listings. It says little about the vendor's support quality, financial health, release discipline or how its staff handle your records. Ask for the vendor's own security documentation, such as a recent independent audit report or a completed security questionnaire.
Where does your data go once the app is installed?
That depends on how the app is built. Some run entirely inside your org, and others send records to the vendor's servers for processing or storage.
A managed package installs components into your org under the vendor's namespace. Its Apex, objects and Flows run on Salesforce infrastructure. A connected app or external client app lets an outside service sign in to your org through the API. That service then reads and writes records from its own environment.
During installation, Salesforce asks you to approve any third-party websites the package will call. Treat that list as a data-flow map. Each domain is a destination for some of your records. Ask the vendor which fields leave the org, where they are stored, how long they are kept and which subprocessors touch them.
How do you check data residency and privacy terms?
Ask for the vendor's data processing agreement, subprocessor list and hosting regions. Then have your privacy or legal team compare them with your obligations. This article is not legal advice.
Your Salesforce contract does not cover the vendor's servers. If your org is hosted in a particular region, an outside service can still process the same records elsewhere. Ask how deletion requests reach the vendor's copies, logs and caches. Our data privacy compliance guide covers the Salesforce side of these obligations.
Which permissions is the app asking for, and does it need them?
Grant only what each user group needs to do its job with the app. Broad installs are convenient on day one and hard to unwind later.
At install time Salesforce offers three choices: admins only, all users, or specific profiles. Choosing all users gives every internal custom profile full access to the package's objects. A tighter approach is to install for admins only, then assign the vendor's permission sets, or your own, to named groups. That keeps access in permission sets, which fits a profile-to-permission-set model.
For any integration user the app needs, ask the vendor for the minimum object and field access it requires. Be wary of requests for Modify All Data or View All Data. Also review the OAuth scopes on any connected app, and restrict who can authorize it.
What will the app cost your org in limits and performance?
Every app spends shared resources: API calls, storage, fields and processing time inside your users' transactions. Measure those costs in a sandbox before production pays for them.
- API calls: an outside service syncing records draws on the same daily allocation as your other integrations.
- Storage: logs, generated documents and history tables can grow faster than your own data.
- Objects and fields: Salesforce documents that custom objects from publicly listed managed packages generally do not count toward your edition's custom object allocation. Fields added to standard objects still affect those objects' layouts and may count toward their field limits, so confirm with Salesforce.
- Transactions: package triggers and Flows can run inside your own saves. That adds processing time and can surface errors your users have never seen before.
Certified managed packages get some per-transaction governor limits of their own, but not all of them. Ask the vendor what runs when a user saves a record on each object the app touches. Our API limits guide explains how daily allocations work.
How does the vendor handle upgrades and Salesforce's seasonal releases?
Find out who controls the timing of new versions. Some vendors push upgrades to subscriber orgs without the customer doing anything.
Salesforce's packaging documentation describes push upgrades as a way for vendors to move subscribers to a newer version automatically. The vendor decides how and when to use them. Ask whether major versions are pushed or left for you to install. Ask how much notice you get and whether you can test in a sandbox first. Also ask how the vendor tests against each Salesforce release preview. Three platform releases a year means three chances for an app to break. Plan app checks into your release readiness routine.
Is the vendor likely to be around, and will it support you?
Judge the company as well as the product.
- Ask how long the app has been listed, how often it ships releases and what is on its public roadmap.
- Read the support terms: response targets by severity, channels, hours and escalation path.
- Ask what happens to your data and license if the company is sold or the product is retired.
Which pricing model fits how you will use it?
Match the pricing model to how usage will grow. The cheapest model at signing can become the most expensive one at scale.
Common structures include per-user licenses, a flat price per org, and consumption pricing based on documents, records or credits. Per-user pricing makes you decide who needs a license, so plan license assignment the same way you plan Salesforce seats. Consumption pricing needs a forecast and an alert before you run out mid-quarter. Ask about sandbox licenses, minimum terms and renewal increases.
| Evaluation area | Question to ask | Red flag | How to test |
|---|---|---|---|
| Need | Does a native feature or small build cover most of this? | Nobody compared native options before the demo | Write the top requirements and map each to native, build or app |
| Security | What independent assurance exists beyond the listing review? | Vendor cites the review as its only security evidence | Request audit reports and complete your security questionnaire |
| Data flow | Which fields leave the org, and where are they stored? | Vague answers about hosting or subprocessors | List the approved third-party sites and trace one record end to end |
| Access | What is the minimum access each user group needs? | Integration user needs Modify All Data | Install for admins only and test with least-privilege permission sets |
| Limits | How many API calls and how much storage per month? | No usage figures for orgs of your size | Run realistic volumes in a full or partial copy sandbox and compare limit usage |
| Automation | What runs when a user saves a record? | Triggers on core objects with no bypass switch | Save records in bulk and through your existing Flows |
| Upgrades | Are major versions pushed, and with what notice? | No sandbox preview before upgrades reach production | Ask for the last few release notes and upgrade notices |
| Exit | How do we export data and remove the app? | Data held only in the vendor's proprietary format | Uninstall from a sandbox and inspect what is left behind |
How should you trial an app in a sandbox?
Install it in a sandbox with realistic data and run a written test plan. A vendor demo org only proves the app works in the vendor's setup.
- Install with the narrowest option, then grant access through permission sets.
- Load data volumes close to production, including your largest accounts.
- Run the top business scenarios end to end with real users, not only admins.
- Test bulk changes, such as data imports and mass updates, with the app active.
- Run your existing automated tests and check that nothing new fails.
- Record API usage, storage growth and any new error emails during the trial.
- Check what a user without a license sees.
What is left behind when you uninstall?
Plan the exit before you commit. Removing an app deletes its components and data, and some dependencies have to be removed by hand first.
According to Salesforce's documentation, uninstalling a managed package removes its objects, fields and related data. You can choose to save an export of the package's data, which Salesforce keeps for about 48 hours. Before you uninstall, remove anything you built that references the package, such as reports, Flows and fields on your own layouts. Data held on the vendor's servers is separate. Your contract should say how you get it back, in what format and when the vendor deletes it. Rehearse the uninstall in a sandbox during the trial.
How much weight should you give AgentExchange reviews?
Use reviews to find questions, not answers. Look for patterns in complaints rather than the average rating.
Filter for reviews from orgs similar to yours in size, edition and industry. Read the negative ones first and note whether the vendor replied and fixed the issue. Then ask the vendor for two references with a similar setup.
Who should approve an app before it is installed?
Set a short approval path that matches the risk. A free utility with no outside data flow needs less review than a paid app that sends customer records to a vendor.
A workable model has the platform owner approve every install. Security and privacy review apps that move data out of the org. Finance approves anything with a contract. Keep a register of installed packages, connected apps, owners, renewal dates and data flows. Review it yearly and remove unused apps. Our security review checklist covers how to audit connected apps and access across the org.
