1

I'd like to create a managed package to release to customers. Salesforce promote 2GP as the way forward for greenfield projects like this.

However, I'm not interested in signing up as an ISV partner, the main application is hosted off platform and this will be a small convenience app for customers to install in their Salesforce orgs to call APIs on the main service.

I'm fine that I'd have to provide the URL to customers wanting to install, I'm fine that this won't go through security review, I'm fine that people will see the banner about it being "non-authorized", that can all be handled.

What I'm keen on learning is whether there are practical implications to using 2GP for this. Salesforce's docs explicitly mention it being the way to develop AppExchange products - but is that just assuming that most will go down that route or is it only for apps delivered that way?

For example, I've heard it suggested that patch releases would not be possible here, because you have to get that configured via Partner support cases, but is upgrading still possible if the major version number is incremented?

Improve this question
5
  • I doubt that you would be allowed to use a managed package (in a contractual sense) for this since Salesforce requires all managed packages to go through security review prior to being offered for sale (and you have to be an ISV or similar partner to do this); an unlocked package would probably be OK (contractually) to use, but these do not protect your intellectual property. You certainly cannot create patch releases of managed 2GPs without going through security review. Both unlocked and managed 2GPs can be upgraded, though local changes will be lost "in" unlocked 2GPs during upgrade.
    – Phil W
    Sep 20, 2022 at 13:53
  • Okay, thanks for the details. At this stage, I don't know whether it would even be for sale, potentially it would just be something the customer could install for free in their org if they need it but with the IP protection of a managed package. I was anticipating that 2GP, on package version creation, would generate an installation URL, just like 1GP, that could then be provided on request. If, on using this URL, would Salesforce then verify that the package hadn't been uploaded on the AppExchange and then block installation?
    – dyson
    Sep 20, 2022 at 14:01
  • 1
    They don't technically prevent install (yes, generating a version gives you the "p0" package version ID that you see in the 1GP install URL, and 2GPs are installed using the same form of URL) but this is a contractual thing. You're going to have to ask Salesforce. Even free managed packages need to go through security review.
    – Phil W
    Sep 20, 2022 at 14:08
  • If the app is purely "convenience" would an unlocked 2GP not suffice?
    – Phil W
    Sep 20, 2022 at 14:09
  • 1
    Yeah, that may very well be the route to go down. In a trade off between the IP protection of a managed package and the formality of becoming an ISV partner for a small app that hasn't got real business logic within it, then it could very well be that the metadata protection is the disposable thing. Thanks!
    – dyson
    Sep 20, 2022 at 14:13

1 Answer 1

Reset to default
1

There are many subscribers who use managed 1GP or 2GP as a way to manage their organization's metadata or provide a feature to one of their clients. The actual documentation states:

Every version of your managed package that you plan to list publicly on AppExchange must go through a security review. The review for a new version of a package that passed a security review is automated, and typically only takes a few minutes.

Note that this is a specific statement of intent. If you do not want to be listed on the AppExchange, you do not need a Security Review. There are two specific expectations for such packages.

First, you can't charge for a package that's not covered by a partner agreement with salesforce.com. This is laid out in the various service agreements that you automatically agree to by use of the Salesforce platform. If you're found out, you can find yourself in court, your package disabled, etc.

Second, you can't do anything that would cause risk or harm to the subscriber or the platform. Causing undue performance loads on Salesforce, stealing or leaking subscriber data, etc. Basically, doing anything that you shouldn't be doing on the platform against the service agreements. Again, the punishments can include legal problems and disablement of your package.

Given your specific statement:

...the main application is hosted off platform and this will be a small convenience app for customers to install...

That's one fair use of a managed package that doesn't need to be listed on the AppExchange, as long as you don't charge for it, or charge extra for the convenience it provides. It must remain completely unencumbered to stay within the rules. As long as you're following the rules, you should be just fine.

Note that 1GP that are limited to a major.minor version system; you can always upgrade to any later version from an earlier version, assuming you do not make it a Beta version. Beta versions can't be upgraded in any org, and cannot be installed in production orgs. For 2GP, you get a full four version numbers to work with (major.minor.patch.build) style version number. This is also true for unlocked packages. That's because 2GP doesn't need a "patch org" or even a "packaging org" to work with.

Note that 2GP has specific restrictions on deleting metadata from the package once uploaded as Released, so the Unlocked Package route might be better, but doesn't offer IP protection. If you want to protect your APIs or secrets, 2GP is the way to go.

Improve this answer

You must log in to answer this question.

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