Managed Package

A managed package is the format Salesforce partners use to build an app and distribute it to Salesforce customers, usually through AppExchange, now called AgentExchange. A package is a container. It holds the parts of an app, such as custom objects, fields, Apex code (Salesforce's programming language), flows, page layouts and Lightning pages. A customer installs the package into their own Salesforce org, which is the company's private instance of Salesforce.

Three features set a managed package apart:

• A unique namespace. Every component carries the vendor's prefix, so its names never clash with the customer's own fields or with other apps.
• Protected code. Much of the vendor's code is hidden and cannot be edited by the customer, which protects the vendor's work and keeps the app stable.
• Upgrades. The vendor releases new versions, and customers upgrade in place. Salesforce supports upgrades only for managed packages. Vendors whose packages have passed Salesforce's security review can also push upgrades to customer orgs directly.

An unmanaged package works differently. It hands the customer an editable copy of the components. The customer can change anything, but the vendor can't send upgrades, so the customer owns all future fixes. Salesforce now recommends its second-generation managed packaging, known as 2GP, for new apps.

Why it matters for lenders

A lender buying Salesforce-based software is really choosing who will maintain it. With a managed package, the vendor carries the cost of bug fixes, new features and keeping pace with Salesforce's own releases. The lender still shapes the app through settings, its own custom fields, reports and flows built around the package.

The key rule is to build on top of the package, not inside it. Changes that sit beside the vendor's components survive upgrades. Heavy custom code that rewires the vendor's logic, or an unmanaged copy, can leave a lender stuck on an old version.

When comparing Salesforce-native products, ask how much of the fit to your programs comes from configuration the vendor supports, and how much from custom code someone will have to maintain.

How it works in practice

A loan fund installs a lending app as a managed package. Its administrator installs it first in a sandbox, a test copy of the org, and runs a few real loans through it. She adds custom fields the fund's grant reports need and builds a flow that alerts staff when a covenant review is due.

Six months later, the vendor releases a new version. The administrator upgrades the sandbox, retests the fund's own flow and reports, then upgrades production. The new features arrive, and her custom fields and flow are untouched, because they sit beside the package rather than inside it.