Salesforce AppExchange Architecture

AppExchange from an Architecture Perspective

The AppExchange is often discussed in commercial terms — which apps are available, what do they cost, what reviews say. For architects and CTOs, the more important discussion is architectural: what does an AppExchange managed package actually do to your org when you install it, and what are the long-term implications of having it there?

A managed package installs Apex classes, triggers, objects, fields, flows, Lightning components, and configuration into your org. Once installed, some of this cannot be removed without uninstalling the entire package. The package runs in your org's execution context, consumes your Governor Limits, occupies your custom object and field counts, and can (with appropriate permissions) access your data. This is a significant architectural commitment, and it should be evaluated as one.

Managed Packages: How Namespaces Work

Every AppExchange managed package has a namespace prefix — a short, unique identifier (typically 3–15 characters) that the ISV registers with Salesforce. All metadata within the package is prefixed with this namespace. An object called Contract__c in a package with namespace acme appears in your org as acme__Contract__c. All Apex classes are acme.ClassName. This namespace isolation is how Salesforce ensures that package metadata doesn't collide with your org's custom metadata.

The practical implication: when you query or reference package objects from your own code, you must use the fully namespace-qualified name. In managed subscriber contexts (your code calling package objects), the SOQL and Apex must include the namespace.

-- Querying a managed package object from subscriber org SOQL
-- Package namespace: 'acme', Object: Contract__c

SELECT Id, acme__ContractValue__c, acme__StartDate__c
FROM   acme__Contract__c
WHERE  acme__Status__c = 'Active'
ORDER BY acme__StartDate__c DESC

-- In Apex, referencing a package class
acme.ContractCalculator calc = new acme.ContractCalculator();
Decimal value = calc.calculateTotalValue(contractId);

-- You cannot see the source of acme.ContractCalculator
-- (it's compiled and protected in the managed package)

Protected vs Public Package Components

ISVs can mark individual package components as "protected" or "public" (globally accessible). Protected components are hidden from subscriber org code — you can use a protected object in SOQL if it's exposed via a package API, but you cannot extend or override it. Global (public) components can be referenced and subclassed by subscriber org code. This distinction determines how extensible and customisable a package is — check the package's documentation for which components are global.

1GP vs 2GP: What It Means for Buyers

First-Generation Packages (1GP) are the original AppExchange packaging model. They're built in a specific "packaging org" and have significant constraints on upgrade flexibility: once a field or object is in a 1GP managed package, it cannot be removed in future versions. ISVs cannot change field data types in 1GP packages. This rigidity means that mature 1GP packages often carry years of legacy schema that can't be cleaned up.

Second-Generation Packages (2GP) are built using the DX model with Git-based source control. They offer cleaner version management, better dependency tracking, and more flexibility in schema evolution. ISVs who have migrated to 2GP can more reliably release clean updates without accumulating the schema debt that 1GP forces.

As a buyer: when evaluating a managed package, ask whether the ISV is on 1GP or 2GP. A 1GP package that has been in market since 2012 is likely carrying significant schema overhead that has architectural implications for your org. A 2GP package has a cleaner evolution path. This isn't a disqualifier, but it's a factor in long-term maintenance assessment.

Security Review: What Salesforce Actually Checks

All paid AppExchange listings must pass a Salesforce security review before publication. The review checks for: Apex code vulnerabilities (SOQL injection, XSS, CSRF), adherence to sharing model (code that bypasses org sharing rules without justification), access to sensitive data without appropriate encryption, and hardcoded credentials or endpoints. The review is thorough by security standards for a platform-level review.

What the security review does NOT check: whether the package's data handling complies with GDPR or other privacy regulations, whether the ISV's backend systems (if the package calls external services) are secure, or whether the package's performance characteristics are appropriate for your data volumes. The security review is a baseline — it's not a comprehensive due diligence replacement.

The Hidden Costs of AppExchange Apps

Beyond the licence fee, AppExchange packages carry hidden architectural costs that accumulate over time. Custom object and field consumption: most packages install custom objects and fields that count toward your org's limits. A large package might consume 20–30 custom objects. For orgs approaching the 200 custom object limit, this is a real constraint.

Governor Limit budget consumption: package Apex code executes in the same Governor Limit context as your own code. A package that runs complex automation on Account records consumes CPU time, SOQL queries, and DML statements from the same transaction budget your custom Apex has. This is rarely disclosed in sales conversations and surfaces as unexplained Governor Limit breaches after installation.

API call consumption: packages that make outbound API calls (to the ISV's own backend) consume your org's Callout limits. Packages that receive data from Salesforce APIs consume your org's API call budget if they use REST/SOAP rather than CDC or Streaming.

Build vs Buy: The Enterprise Architect's Framework

The build vs buy decision for Salesforce functionality is not just a cost calculation. Architectural factors that favour buying (AppExchange): the capability is not strategic differentiation (billing management, e-signature, document generation — commodity functionality), time-to-value is critical, and the vendor has deep Salesforce expertise and a strong release cadence.

Architectural factors that favour building: the capability is a source of competitive advantage, the data model of available packages doesn't fit your requirements without significant customisation, the package's Governor Limit consumption profile conflicts with your existing automation, or your data governance requirements preclude data leaving your Salesforce org to an ISV backend.

Evaluating an AppExchange App Before Installation

A structured evaluation process for enterprise architects. Step 1: Install in a full copy sandbox, not production. Document every object, field, and Apex class added to the sandbox after installation. This is your installation inventory.

Step 2: Run performance tests with your org's representative data volumes. Trigger the package's automation on batches of 200 records and monitor Governor Limit consumption in the debug log.

Step 3: Review the package's Apex triggers on objects you customise. Do they conflict with your existing automation? Do they use without sharing in ways that bypass your security model?

Step 4: Review the ISV's DPA and data processing documentation for any external API calls the package makes. Confirm compliance with your data governance policies.

Step 5: Document the uninstallation path. What dependencies would need to be removed to uninstall the package cleanly? This is the measure of how locked-in you become over time.