I've been doing some trailhead and there was a paragraph:

"Meet Sally, Gunjan, and Ali. These three amazing developers are working on an exciting new Salesforce app, and tomorrow is the big launch day. Sally and Gunjan have been working in developer orgs, and Ali in a sandbox org. Sally creates an unmanaged package and pushes it to the sandbox org. Gunjan does the same. What could go wrong?"

This got me confused, because there are these types of sandboxes:

  • Developer Sandbox
  • Developer Pro Sandbox
  • Partial Copy Sandbox
  • Full Sandbox

What's the difference between developer org and sandbox org?

2 Answers 2


There are actually multiple types of Developer Edition and Sandbox Orgs. Depending on your relationship with Salesforce, and what subscription you have, different options may be available.

For Developer Edition, you can get a free Developer Edition for personal use; if you are an ISV (an AppExchange publisher), you can get a Partner Developer Edition, created through the Environment Hub, which has enhanced record storage and the ability to get features/limits modified (the personal version does not allow this). This help article shows the difference between the two types. Developer Edition Orgs are always free, though being a Partner does have associated costs, so you might interpret "free" as "they never incur an upcharge."

For Sandboxes, they come in various sizes, including Dev, Dev Pro, Partial Copy, and Full Copy sandboxes. Every Professional, Enterprise, and Unlimited Edition paid org gets a lot of Dev Sandboxes, and various editions may include Dev Pro, Partial Copy, and Full Copy Sandboxes. Dev Sandboxes have the smallest storage, followed by Dev Pro, while Partial Copy and Full Copy sandboxes have 100% the storage capacity of production. The Partial and Full Copy Sandboxes take the longest time to set up and can only be refreshed once a month, while the Dev ones can be refreshed once per day.

Sandboxes are always linked to a Business Org and will cease to function if the Business Org is disabled. In that sense, Sandboxes are not "free" orgs. You can purchase more Sandbox Licenses if you need more than the default allocation. For example, you can purchase a second or third Full Sandbox (but the cost of this is prohibitive). In addition, all Sandboxes can be "connected" together to deploy metadata via Change Sets, and these Sandboxes can also migrate metadata directly to the attached Business Org this way as well.

Developer Editions come with some default template data, depending on the form you use to sign up from. You need to migrate metadata and data to the org before you can do any work with it. Sandboxes, in contrast, at minimum, will come with all the metadata from the Source Org (which can be a Business Org or another Sandbox Org), and the Full and Partial Copy Sandboxes also come with data from the Source Org, optionally limited or selected by a template subscribers can set up.

Sandboxes also recreate all the users from the Business Org, while Developer Edition orgs only get a couple of user licenses. Developer Edition Orgs, however, get a bunch of licenses that you would normally have to pay for, such as Community Licenses, which Sandboxes do not get by default (but you can typically ask Support if you want to test such licenses). In this sense, Developer Editions do have at least that advantage.

Migrating a package via Unmanaged Packages is a non-trivial affair. These packages can't be upgrade and will conflict with existing metadata in the org. They should really only be used for one-off scenarios where you expect to never update the package. Originally, these packages were meant as a way to move metadata from a Developer Edition org into a client's Business Org. I don't recall for sure, but I think that Unmanaged Packages probably predate even the Metadata API.

Developer Edition orgs are primarily designed for developing and testing a product that may eventually end up on the AppExchange, and also serve as a way to learn how to use Salesforce in an isolated environment. They have severe limits on storage space, API calls per day, how many emails you can send daily, and so on. The two large Sandboxes basically have the same limits as the Business Org they are created from, including API calls per day, email limits, etc.

Finally, Developer Edition orgs have the ability to take on a Namespace or operate as a Dev Hub, while Sandboxes can do neither. Namespaces allow for Managed Packages to be installed without conflicting with unmanaged metadata, unlike an Unmanaged Package. Dev Hub allows you to create Scratch Orgs, which are another type of limited-time Developer Edition Orgs that you can create, although Developer Edition can only make 6 Scratch Orgs a day and have 3 active Scratch Orgs, while a Business Org Dev Hub can create up to 100 Scratch Orgs.

In summary, Developer Edition orgs are for development of products, while Sandbox Orgs are meant to develop and test subscriber-specific customizations as well as for User Training.


A sandbox org (developer, dev pro, partial copy, full copy) are attached to a (paid) Production org. Sandboxes can be refreshed so that they contain all of the same metadata (SObjects, custom fields, remote site settings, apex classes, etc...) of another org (typically the production org).

A developer org (a.k.a. the Developer Edition of SFDC) is different from a developer sandbox org. Developer orgs are free, and have some pretty strict limitations put on them (to prevent businesses from running off of the free version) like a piddly 5MB of storage space and not being able to create sandboxes.

  • I see. Thanks for the clarification. Is it really possible to create a developer org based on some of your personal emails and connect it to a sandbox org? How would a user send an unmanaged package from a developer org to a sandbox org?
    – DevelBase2
    Mar 25, 2022 at 15:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .