ChatGPT
Claude
Google AI
Copilot
There is no honest list of the best AppExchange apps for a digital transformation. Rankings go stale, they rarely match the cloud you run, and they are often someone else's advertisement. Evaluate the package in front of you. Four questions are enough. Is it managed or unmanaged. Which objects does it lock. Is the security review current. How do you leave.
The failure is an entitlement that lives only inside a package you can no longer change. The listing looked like a small utility. It was unmanaged, so the install copied components into the org and then stood still. A year later the vendor's next version arrives as another pile of components, with no link to the first. The appointments, or the consent rows, or the subscriptions, sit in objects you did not design and cannot extract cleanly. Uninstalling drops them. A rating on the listing did not mention any of that. The rating was never the evaluation.
Salesforce already lets you build agents in Agent Builder, with platform tools, including standard and custom subagents and actions. Agentforce Field Service and Operations, formerly Field Service, is already a field service hub. If the job is one of those, an app that becomes a second system of record is the risk. If the job is neither, the four questions still apply. The listing's badge does not answer them.
Managed or unmanaged
A managed package has a namespace. The vendor can ship upgrades. You generally cannot change their code, and you generally cannot delete their objects while the package is installed. That is the right shape when you expect the vendor to maintain the product and you have tested how you get data out. The namespace is the point. The fact lives in their shape for as long as the package is installed. You are renting the shape. You should know that before you put a record there that you must keep.
An unmanaged package is a copy of components. After install, you own them. The vendor has no upgrade path into your org. That can be acceptable for a small utility you intend to keep and change yourself. It is a poor way to buy a product you expect to stay current, because the next version arrives as another pile of components, with no clean link to the first. You will then have two of everything, and a temptation to keep writing to the old objects because something still points at them. Read which kind the listing is. A demo that never says is not finished. Ask in the first meeting, and write the answer on the evaluation page. If the seller does not know, they are not ready to sell it to you.
Neither kind is morally better. They fail differently. Managed fails when you need to change a behaviour the vendor will not change, or when you need to leave and the export was never tested. Unmanaged fails when you needed the vendor to keep the product current and instead you inherited a snapshot. Pick the failure you can live with. Do not discover it from the install log.
What it locks, and how you leave
List the objects the package creates, and the standard objects it writes during normal use. A custom object in the vendor's namespace means that fact lives in their shape for as long as the package is installed. If the fact is something you must keep after you leave, entitlements, consent, subscriptions, the appointment, you need an export you have already run, into a place you control.
Writes to standard objects are the quieter lock. A package that updates the account, the contact, or the opportunity during ordinary use is now a writer on records you thought you owned. That writer needs the same treatment as any other integration. One direction, named fields, and a system of record that is not "whichever package ran last". Who owns each of those fields, apart from this package, is the programme question in integration at programme level. If the package must be the owner of a field, say so, and do not also let the CRM and the ERP write it. If the package is not the owner, it does not get a silent update. A convenience that "keeps the account in sync" is a second writer with a friendly name.
Leaving means that export, a destination for the rows, and an uninstall you have tried. An app that is the only copy of a record, with no export, is not an app you can make the system of record. Use it as a convenience on top of a record you already own, or do not install it. Run the export in a sandbox before you depend on it, on a volume that looks like production, not on three demo rows. How a sandbox differs from the other clouds you might think came with it is in testing multi-cloud integrations in a sandbox. An export that only works while the package is installed, into a format only the package can read, is not an exit. It is a brochure.
Time the exit. If the vendor's contract ends on a Friday, you need the rows out before that, in a store you can open on Monday without their login. Put that drill on the calendar in the same month you install, while the people who understand the objects are still around. An exit plan written the week the contract is cancelled is a hope. The objects will be less documented then, not more.
The security review
The security review is a separate stop. Read the status on the listing and the date. If you cannot tell whether the review is current, wait until you can. A feature list does not outrank a review you cannot verify. You are about to let this package run in the same org as your customer data. "The vendor said it passed" is not the listing. Open the listing. If the date is older than you are willing to accept, ask what changed in the package since, and whether those changes were reviewed. A package that has grown three objects since the review is not the package that was reviewed.
This is not a ranking of reviewers, and it is not a claim that a review makes the package fit your org. The review is a gate you can observe. Fit is the four questions, plus the fields it writes. A current review of a package that locks your only copy of consent is still a package you should not make the system of record. Pass the gate, then do the rest of the evaluation. Do not let the gate replace it.
Build, buy, or use the product you already have
For a small action, a screen, a guided step, a subagent that calls a flow you already trust, building on the platform is often the smaller commitment. Agent Builder exists for that. Use it when the job is yours and narrow. You will own the result, including the upgrade, which is the point. Do not build a second scheduling system because a package looked heavy. Do not buy a package because a flow felt boring. Boring and yours is often the better exit.
For a product you do not want to maintain, a managed package with a review you have checked and an exit you have tested is a coherent buy. Write down who inside your organisation accepts the vendor's upgrades, and how an upgrade is tried before it reaches production. An upgrade that arrives on a Tuesday and rewrites a standard object is an integration change. Treat it as one. The person who owns that object has to have seen it.
For scheduling technicians, look at Field Service before you look at a listing. A second scheduling system that owns the appointment becomes the thing you cannot turn off, which is the opposite of what a transformation was supposed to leave you able to do. The platform hub is already the field service product. A listing has to beat the exit cost of a second appointment, not the demo of a nicer calendar.
A rating on the listing does not answer the four questions. Neither does a place on someone else's list. There is no ranking on this page, and there will not be one. The package in front of you is the evaluation. If it cannot survive the four questions, it is not a transformation. It is a dependency you have not priced.
The page you fill in before install
One page, four answers, written before anyone presses install. Managed or unmanaged, copied from the listing, not from the demo. The objects it creates, and the standard objects it updates in ordinary use, named. The security-review status and the date, or the words "cannot tell", which means wait. The export you ran: where the rows landed, whether you could open them without the package, and the date. A page with a blank export line is a decision to let the package be the only copy. Do not leave that blank by accident. Leave it blank only if you have decided the package is a convenience on records you already own, and write that decision on the page.
Walk a scheduling example without pretending a listing is a winner. The job is appointments. Field Service already holds work orders on the platform. A package that also creates an appointment object is asking to be a second system of record. The page should say so in the lock line. If the export of those appointments failed, or was never run, the package does not get the job. Use the hub you already have, or build the narrow screen yourself in Agent Builder and a flow you trust. That is a dull outcome. Dull is how you stay able to leave.
The page is also what you show a second firm, if you ask one to implement the package. They do not get to skip it because they know the app. The firm linked from a services page is not a reason to skip it either. The questions are the evaluation. A partner who will not sit with the page is telling you the install matters more to them than the exit. That is useful information. It is not a reason to install. Keep the page with the install record. The next person who inherits the org should be able to see the namespace, the export date, and the review date without opening the listing again.
