Master Salesforce ISV: Managed Packages, 2GP & AppExchange Security

💬 In plain words: Building a product on Salesforce is completely different from building for a single company. As an Independent Software Vendor (ISV), your code ships as a managed package into thousands of customer orgs you will never see. A unique namespace isolates your work, you must pass a rigorous AppExchange Security Review, and your automated upgrades must never break a customer’s existing setup.

📌 Example: Your managed package works flawlessly in 9,999 orgs. But org 10,000 has Person Accounts enabled, multi-currency activated, and another package's trigger conflicting directly with yours. You cannot log into their system. Instead, you must rely on the telemetry your package writes and rebuild a scratch org matching their exact configuration to reproduce the bug. Welcome to ISV life!

🔑 Key Points

• Namespaces are your shield: They prefix your objects, fields, and classes so your code never collides with a subscriber's custom configurations.
• Code is hidden: Your Apex source code is entirely hidden from the subscriber.
• Global APIs are forever: Once you release global classes or package fields, they become permanent contracts. You cannot simply delete them later.
• 2GP is the standard: Second-Generation Packaging (2GP) is modern, source-driven, version-controlled from Git, and built natively for Continuous Integration (CI).

🧠 Ship to Orgs You Cannot See: A managed package places your code into thousands of invisible orgs. Always design defensively for the most complex, chaotic org imaginable.

⚙️ The Core Concept: ISV Architecture

A managed package is the fundamental delivery unit for a Salesforce ISV. But because you lose control of the runtime environment, your entire development mindset must shift. Every feature you build must assume the worst about the target org.

The AppExchange Security Review is mandatory, rigorous, and completely unforgiving. You must enforce Create, Read, Update, and Delete (CRUD) as well as Field-Level Security (FLS) in absolutely every code path. Modern developers achieve this using WITH USER_MODE or Security.stripInaccessible(). Queries must be injection-safe, and hardcoded secrets are strictly forbidden.

Operationally, you manage your business using the License Management App (LMA), which tracks installs and licenses per subscriber. When it is time to update your app, you use Push Upgrades to update customer orgs automatically. The golden rule of push upgrades? You must be a good tenant—your updates can never break existing subscriber behavior.

⚠ INTERVIEW TRAP: Never treat the AppExchange Security Review as an afterthought. Retrofitting CRUD/FLS and injection protections into a finished codebase is pure misery and often requires rewriting core logic. Build security into your Continuous Integration (CI) pipeline from day one.

🧭 360 Card — ISV & AppExchange

• Rule: You are shipping into thousands of orgs you cannot see. Assume nothing about any of them.
• Gain: A namespace seals your metadata, ensuring your code cannot clash with a customer's custom logic.
• Price: You lose complete control of the runtime. You must handle their configuration, their locale, their data volume, and their other installed packages.
• Limits: Managed packages are locked down. The Security Review will catch the exact injection and access mistakes you would normally get away with internally.
• Mirror: When building for a single company, you can log in, view the debug logs, and fix issues live. An ISV does not have this luxury.
• Later: Debug by org shape, not by direct access. Gather their specific features, locales, and currencies, then rebuild the exact scenario in a scratch org.

❓ Core Q&A

Q: What changes about how you write Apex and design features when shipping a managed package to thousands of orgs?

🎯 Say this first: You lose control of the runtime. Assume absolutely nothing about their org's configuration.

A: You must adopt three major mindset shifts:

• Defensive by Default: You cannot know the subscriber's sharing model. Every SOQL query and DML operation must strictly enforce CRUD and FLS (using WITH USER_MODE). You cannot assume features like multi-currency or Person Accounts exist—you must use dynamic describe checks and build in graceful degradation.
• Contracts are Forever: Anything marked global becomes an API that customers rely on. You cannot delete it later; you can only manage its deprecation across version releases. Always expose the absolute minimum surface area required.
• The Pipeline is the Product: You must use 2GP source-driven packaging. Your test matrix must validate against different org shapes (features toggled on/off, various locales). Security checks must happen in your CI pipeline, not during the AppExchange submission.

🚀 Scenario-Based Follow-Ups

🎬 Real-Life Example: The Invisible Bug

Q1: A subscriber reports your package breaks only in THEIR org. You cannot log in to see the error. How do you debug it?

A: You reproduce the issue by shape, not by access. First, ask the customer for their exact org configuration (enabled features, locale, currency, co-installed packages). Second, spin up a scratch org using a definition file that perfectly mimics that configuration.

Simultaneously, rely on your package's custom telemetry—structured error logs that a good ISV designs into the package specifically for this scenario. Most "only in our org" bugs are simply untested org-shape combinations, like a disabled feature flag or a clashing locale format. Once you find it, ship a patch, and permanently add that org shape to your CI test matrix.

Q2: 1GP vs 2GP — does it really matter today, and what is your advice for a company still on 1GP?

A: For any new product, 2GP is the only answer. There is no debate. It is source-driven, CI-native, supports multiple versioned packages from a single Dev Hub, and handles dependencies infinitely better than 1GP.

However, an established vendor on 1GP faces a complex migration path, not a simple checkbox switch. Namespaces and certain system behaviors differ between the two. My strategic advice: build all new modules in 2GP to stop the bleeding, and plan a phased migration for the core product so that packaging archaeology doesn't bring your active release train to a grinding halt.

🔗 Connecting the Dots

Follow-up for you: How would you architect a custom error-logging framework inside your managed package that safely surfaces telemetry data back to you without violating the subscriber's data privacy?