Package Development Model vs Org Development Model

Two Models, One Platform

For most of Salesforce's history, there was one way to build: you worked directly in a sandbox, deployed changes through change sets or the Metadata API, and your production org was the source of truth. This is the Org Development Model — and despite years of Salesforce pushing alternatives, the majority of enterprise teams still use it.

In 2017, Salesforce introduced Salesforce DX and, with it, the Package Development Model. The premise: your source code lives in version control, not in an org. Orgs become ephemeral environments — spun up for development and testing, discarded when done. Deployable units become packages with explicit version numbers. It's the model that ISVs and AppExchange publishers use, and Salesforce believes it should be how everyone builds.

Both models are real, supported, and used in production today. Understanding the genuine trade-offs — not the marketing version — is what this tutorial is for.

Org Development Model: How Most Teams Still Work

In the Org Development Model, your production org (and its sandbox copies) is the system of record. Developers make changes in sandboxes, promote them through an environment hierarchy — typically Developer → Full Copy → UAT → Production — and the final state of the org is what you manage and protect.

This model is intuitive because it maps directly to how Salesforce presents itself: a system you configure through a browser. Adding a field, building a flow, writing an Apex class — all done in a live org, visible immediately, testable immediately. There's no build step, no compilation, no deployment pipeline to set up before you can start working.

Why It Persists

The Org Development Model persists because it works. For teams building business applications — as opposed to ISVs building products — the ability to see changes in context, test configurations against real data in sandbox, and promote them through a controlled hierarchy is genuinely effective. Change sets, while clunky, are understood by every Salesforce admin and developer in the market.

The model also requires no tooling investment beyond what Salesforce provides. No CLI configuration, no Git workflow for Salesforce metadata, no scratch org provisioning, no CI/CD pipeline. For teams without a DevOps function, this is a significant factor.

The Problems That Emerge at Scale

The failure modes of the Org Development Model all appear at scale. When multiple teams are making concurrent changes in the same sandbox, conflicts are discovered at deployment time, not at commit time. The production org becomes a complex, interconnected state that's difficult to reproduce cleanly. Rollback is nearly impossible — you can't undeploy a field that has data in it. And testing relies on the assumption that your sandbox accurately reflects production, which it often doesn't after months of divergence.

Package Development Model: The Promise

The Package Development Model flips the source of truth. Version control — Git — holds the metadata. Orgs are generated from source, not the reverse. A scratch org is a temporary, purpose-built environment that reflects exactly what's in your repository. When work is done, the scratch org is deleted. The artifact you promote through environments is a package version, not a change set.

This aligns Salesforce development with how modern software teams work. Your CI/CD pipeline can create a scratch org, deploy your package to it, run tests, and discard the org — all in an automated pipeline. Branches in Git correspond to feature work, not environment states. Merge conflicts surface in code review, not at deployment time.

What Scratch Orgs Actually Are

A scratch org is a temporary Salesforce environment provisioned from a definition file. It has no historical state — it's built from your source code and whatever sample data you load. Scratch orgs have a maximum lifespan of 30 days (default 7). They're not sandbox copies; they're clean environments that prove your code works in isolation from any specific org's accumulated configuration history.

# Create a scratch org from a definition file
sf org create scratch \
  --definition-file config/project-scratch-def.json \
  --alias my-feature-branch \
  --duration-days 7

# project-scratch-def.json
{
  "orgName": "SFVedas Feature Dev",
  "edition": "Developer",
  "features": ["EnableSetPasswordInApi"],
  "settings": {
    "lightningExperienceSettings": {
      "enableS1DesktopEnabled": true
    }
  }
}

First-Gen vs Second-Gen Packages: The Decision That Matters

Salesforce packages come in two generations, and the distinction matters significantly for enterprise buyers and architects evaluating AppExchange products.

First-Generation Packages (1GP)

1GP packages were Salesforce's original packaging mechanism for ISVs. They're managed or unmanaged packages created in a specific org (called the packaging org) and installed into subscriber orgs. 1GP packages have significant limitations: they can't be version-controlled in the same way, their development model ties them to a specific packaging org's state, and upgrades are complex because field deletions and certain changes aren't allowed in managed packages.

Second-Generation Packages (2GP)

2GP packages are built using the DX model. Source lives in version control. Package versions are created via CLI commands, not through an org UI. 2GP supports multiple packages that can depend on each other (unlocked packages), proper semantic versioning, and a development workflow that integrates naturally with Git branching and CI/CD pipelines.

For new development, 2GP is categorically superior. For teams with existing 1GP packages, migration is possible but requires careful planning — particularly around namespace management and subscriber upgrade paths.

The Reality of Migration

Every Salesforce partner and most large enterprise teams have been told they should migrate to the Package Development Model. Far fewer have done it completely. The gap between the recommendation and the reality reveals genuine friction that deserves honest acknowledgement.

The Tooling Learning Curve

The Salesforce CLI (formerly SFDX CLI, now SF CLI) is the entry point to package-based development. It requires every developer and admin to work in a terminal, understand Git branches, and think in metadata files rather than org configurations. For teams where many contributors are declarative developers — admins using Flow Builder and the setup menu — this is a significant skill change, not just a tool change.

The Org State Problem

Most existing orgs contain years of accumulated metadata — some deployed intentionally, some the result of trials and experiments, some from AppExchange packages, some that nobody can explain. Migrating to source-driven development requires that your source code accurately reflects what's in the org. The process of achieving this — called "spidering" the org — is time-consuming and frequently surfaces surprises.

Partial Adoption Is Common (and Acceptable)

Many successful enterprise teams use a hybrid: new custom development uses the Package Development Model and unlocked packages, while legacy metadata that predates the migration remains managed via the Metadata API. This is not failure — it's pragmatic. The goal is directional, not binary.

Which Model Is Right for Your Programme?

The honest answer depends on several factors that vary significantly between programmes.

Choose Org Development Model if: your team is primarily declarative (flows, configuration), your programme is short-term (under 18 months), you don't have a DevOps function or Git-literate Salesforce team, or you're building on top of a heavily-customised legacy org where source retrieval is unreliable.

Choose Package Development Model if: you're building a new org from scratch, you have multiple development teams working concurrently, you need the auditability and reproducibility of a modern software delivery pipeline, you're building something that will be maintained for 5+ years, or you're an ISV building a product.

Choose Hybrid if: you have a significant existing org, some teams are ready for package-based development and others aren't, or you want to migrate incrementally without disrupting ongoing delivery.

What Good Looks Like

Regardless of which model you choose, certain practices separate programmes that control their Salesforce delivery from ones that are controlled by it.

In the Org Development Model: maintain a rigorous environment hierarchy, use a proper CI/CD tool (Gearset, Copado, or Flosum) rather than raw change sets, treat your full copy sandbox as a pre-production environment that matches production within 72 hours, and establish a clear policy for what changes require code review vs what can be self-deployed by admins.

In the Package Development Model: invest in developer onboarding to the CLI and Git workflow, define your package boundaries carefully before building (package refactoring is expensive), establish scratch org creation as part of every developer's daily workflow, and build automated test suites that run against scratch orgs in CI before any merge to main.