function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

Managed Package naming - looking for recommendations


In the process of planning to publish an app - and more apps to follow that relate to the first one, what's the recommendation for naming the managed package (from one org) vs naming the custom app(s) within it? If my first app is named X, can the managed package also be named X? Or should the package name be more like 'X Pack'?

Also, how are package and app names presented in the directory - are they both listed? Is a prospective installer aware that an app is available within a package? Is (s)he installing the package as a whole or just the app?



Prospective users can view the components of a package by selecting the specifications tab of any app on the app exchange.  If you are planning to have an application that has a base set of features and a set of optional or related features you may want to structure those as a base package with extensions.  If your base package is managed, it can be supplemented by either managed or unmanaged extensions.  For example, if I wanted to create an application that I could market to both PE and EE users, I could put all of the functionality common to both PE and EE in the base package, and add EE specific functionality in the extension (for example workflow).  The base package would work for both, the extension only for EE users.  This method can also be used to segment an app by functionality or other criteria.  

Thank you for your clarification. Without beating this to death, I would like to explore how best to make use of the 'package' capability in the following respect:

Let's say I plan to produce a few apps that will, when they all exist, belong to a 'family'. For example, a group of apps catering to an objective "Finding (people) resources to develop AppExchange apps". The apps, individually, may be "Online search", "Alerts (search agents, or bots)", "ERP integrator", etc. As I believe a managed package can contain multiple apps (?), should I create one package, named "App Resources", containing apps "Search", "Alert", and "Integrate", allowing user to buy each app individually as and when they need them? In this case they would all be seen to be part of the "App Resources" package. Or should these be individual apps each in their own package?

In the absence of any reply to my request for clarification, I will take a stab at this and say that, although there seems, on the surface, to be a one-to-many capability between a (managed) package and a custom app (ie. having defined a package and given it a name, you then define your custom app to be contained within it), it is not meant to contain multiple apps, but rather, as GregC kindly explained, 'extensions' that cater to different needs (possibly different types of SF customer).

If anyone knows I am wrong here, I would appreciate any comments.