3

We have a managed package on the AppExchange that various customers use. We develop this using SFDX and follow the usual processes of having unit tests with appropriate coverage etc. as required. As per Salesforce constraints we only add new components in new release versions (rather than in patches, where new components generally can't appear).

Every now and then, when developing new releases of the product, we have to add some new global Apex or change product behaviour in some way that might cause issues on customer orgs.

As such we want to be able to create a beta release since this doesn't lock the changes in if we need to re-work something based on "real life learning". This "real life learning" can only really be achieved by installing the beta in a sandbox created from one or other customer's production org.

We find that it is impossible to install the beta on such a sandbox:

Install Failure

It seems that as soon as an org contains even so much as a validation rule or report that references a field added by the package (or any other component that references any component from the package) it becomes impossible to upgrade the package on the org with a beta release. And that makes beta releases basically useless for gaining any "real life learning" or performing any real-world testing.

While I am happy to accept that after installing a beta you can no longer upgrade the package in that org (and must therefore essentially discard the org or refresh the sandbox before continuing) I don't understand why the initial installation of the beta doesn't work the same as installing a release version.

Does anyone know why this is the case? Is there a workaround that doesn't involve removing every single reference to every single component of the package?

Your Answer

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

Browse other questions tagged or ask your own question.