I'm working on a project that is extended by another package. The base package contains a global interface that will be implemented in the extension package. I'm having some problems with the development of the interface. My problem is that after I've uploaded a managed release of the base package the global interface can no longer be changed. It would be possible to upload a managed beta, but that I won't be able to update that in the extension environment without uninstalling it.

I need to able to upload a managed release of the base package and still be able to alter the global interface (because during the development of the extension class, the requirements for the interface change). Is that possible?

Suggested solution

What if I created 2 interfaces in the base class like this:

public virtual interface BaseInterface {
    //all the function definitions that need to be in the global interface


global interface GlobalBaseInterface extends BaseInterface {
    //no actual content

If I were to package these two interfaces and upload a managed release; would I still be able to alter the contents of the public virtual interface BaseInterface? And will the function definitions within that interface be visible in the extension package?


I actually tried the solution above and, as Stephen Willcock said, the functions are not visible. Although this works if you make sure you implement all the functions, the problem is that you will not get a compile time error if you don't implement one of the functions. If that function is used in the code you will get a run-time error. So it could be useful to do it like this; it could be very dangerous as well.

  • Nice try :-) you will be able to change the public interface but you should not expect the methods to be accessible in the extension package Commented Jan 11, 2013 at 14:08

2 Answers 2


As you have found, global interfaces in a released managed package cannot be changed. For versions of global interfaces across versions of your base managed package your only option is to add new versions as new (and distinct) interfaces. I would suggest adding a version number to the interface name - I am not suggesting using package version numbers, but a simple integer incremented each time a new version of the interface is required.

This could be useful in your development cycle before releasing your packages, but will quickly pollute your package with redundant interfaces. However, for a small project this may be sufficient.

For a larger project, I would suggest solving the problem by adapting your development process. I would develop your product unmanaged and unpackaged. Keep the code for your two packages quite separate in a source control system, and deploy both to the same developer org, base package code first and then extension package code. The interfaces will be global, but are malleable as they are unmanaged.

Having completed your development for a releasable version in an unmanaged environment, you can start your release cycle. In your release cycle you would build first the main package and then the extension package in a separate packaging exercise.

Once you have a stable base package, upload a release version and use this to start building the extension package.

  • Thanks for your answer. If I would install the unmanaged versions of the base package and extension package in new environment, what would be the easiest way to recapture the appropriate code to the development environment for the individual packages after I have developed a release candidate? And is there a way to do an unmanaged upload of a package that can also be uploaded managed? Commented Jan 11, 2013 at 14:12
  • You won't be able to create separate unmanaged packages - I was suggesting unpackaged and unmanaged code, deployed via metadata API. Commented Jan 11, 2013 at 14:17
  • I haven't got any experience with the metadata API, I'll check that out. Thanks again. Commented Jan 11, 2013 at 14:18
  • Re recapturing the source and separating into packages - if you are disciplined about using source control systems, you should be able to create separate Eclipse projects each based on a different source control folder, while both projects are bound to the same org. Commented Jan 11, 2013 at 14:21
  • Could you give me some pointer where to start using the metadata API? Maybe something like a tutorial? Commented Jan 13, 2013 at 10:21

Lex, the Metadata API is what is used to deploy your code from your Force.com IDE (eg. Eclipse). http://wiki.developerforce.com/page/Force.com_IDE

You may also want to vote up this idea for change management of global interfaces, https://success.salesforce.com/ideaView?id=08730000000kmYbAAI

You must log in to answer this question.

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