Suppose, several developers are working on the same project. And, we need to create a managed package. Since the managed package has a namespace prefix, the other developers need to develop based on that namespace prefix and put prefix where it is needed. Please refer to the image below (This is what I expect):

Managed Package Expected Flow(Not possible)

However, this is not possible. Because the namespace prefix can't be shared with the developer edition org. Only can be shared with the Scratch org, but Scratch org expires within 30 days, which is more of a hassle.

So, now my questions/concerns are below: (Multi-devs, one namespace for all)

  1. What's the proper way of development for Managed Packages? (I didn't find any straightforward resource. I checked ISV guide, Trailhead, etc. and I'm still confused)
  2. I have tested Scratch org, it can be helpful with my intention, but I find it inconvenient because of the 30 days limit.
  3. I have an Enterprise Edition org, so making multiple orgs/sandbox, etc won't be a problem. So, is there any way I take the advantage of the Enterprise Edition org and achieve what I want as per the image? Or, please guide me if there are any better ways.

Please don't refer link which doesn't clear my confusion or help me with my intention. Thank you!


There are multiple routes to take into consideration here.

Second-Generation Packaging

Your question implies that you’ll be using first-generation packaging (1GP). This is an obsolete and limited packaging technology. As a general rule, absent any specific limitations requiring the use of 1GP, all new packages should be developed using second-generation packaging (2GP).

2GP packages are always developed in scratch orgs using source control, which is a modern best practice.

1GP with Namespaced Scratch Orgs

1GP packages can be developed by a distributed team using namespaced scratch orgs. The thirty-day lifespan of the scratch org should not be a significant problem since your source of truth should be a version control system.

1GP or 2GP without Static Namespace References

If you avoid explicit namespace references in your metadata, you can preserve your ability to deploy managed package source code into non-namespaced orgs, whether scratch or persistent.

This can be challenging to do effectively and often requires a technique like the namespace injection found in CumulusCI (my team’s tooling).

In summary: you are attempting to target a development process that is obsolete and not representative of modern standards and best practices. While there are routes to get some of what you want, your overall experience will be much better if you use the current state of the art: 2GP, source control, and scratch orgs.


On your point 2), being able to create working scratch orgs quickly and in a fully automated way is an important part of the model; that can take time to achieve. But once you are there, you can do continuous integration (CI) builds too which is a big help. One of my colleagues is working at the moment so we can have a good quantity of data setup quickly too, using David Reed's team's CumulusCI tooling.

We work now using scratch orgs and 2GP. Personally, I create my own dev scratch orgs with the 30 day limit set and work on many features in that one org. Only re-creating the scratch org occasionally means that task is not onerous. We presently use GitHub Actions to do our CI builds where the action calls SFDX commands. Those orgs are set to expire in one day, though they are also explicitly deleted.

I recommend investing time in moving to scratch orgs; it will pay back quickly.

(An example of another scratch org benefit: when creating a managed package, you typically want it to work in multiple org configurations e.g. with or without Person Accounts or with or without Platform Encryption turned on. With scratch orgs you can create multiple configurations of org and deploy and test your code against each one as part of your CI.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.