We have a pure Force.com app (no outside integration) on the AppExchange. Our customers are asking us if we can offer a way for them to load datasets into certain custom objects in our app. We will author these datasets. Each customer would want a different set of records and some would choose not to load any data at all, so we don't want to load the data in an InstallHandler script, for example. In addition, we will be adding more datasets over time, so I don't really prefer embedding them in the app (e.g. as static resources) and pushing a new version of our app with each new dataset.

Here are some of the options I'm considering (in rough order of my preference) and I'm wondering if folks have some feedback or additional ideas:

  1. Host the data on an external site and create a page within the app to view and download datasets on demand (pros: we can update data whenever, flexibility to add/update datasets; cons: external system subject to security review, maintenance of a second system)

  2. Create one managed package per dataset ("content pack"), where the data is embedded in a static resource. An InstallHandler installs the data. (pros: fairly simple for users, more presence on AppExchange; cons: one security review per package; multiple packages to maintain)

  3. Create one unmanaged package per dataset, similar to #2. Since OnInstall is not available, create a new VF tab, where the user will press an "Install" button. (pros: no security review; cons: poor UX, need to distribute links to unmanaged packages on our own website)

  4. Build datasets into core managed package and release a new package version with each new dataset. Like #1, users use a page to see and install datasets (pros: good UX once managed package is updated, continued use of "native" app means no security review issues; cons: users need to update managed package to get new datasets)


1 Answer 1


It seems that all 4 options you present require you to add something into your managed package. Option 1 is the lightest in this sense but still requires adding a page which pulls in the external app.

So, perhaps an Option 5 to consider is a simple Heroku app that your clients can hit in a browser, connect to their org via OAuth, and load data via the API. Having the app run on Heroku would make the maintenance burden pretty light.

By using OAuth, you wouldn't actually have to make any changes in your managed packages. You'd just have a url the clients visit to load data sets. Since there are no references to the app contained in your managed package, I'm not sure if you'd need a security review of the Heroku app itself.

We built a Heroku app called mrbelvedere which we use to help our users install and upgrade multiple managed packages and some unpackaged metadata in a one step process. It uses OAuth to interact with the Metadata API. We also do some interaction with the data api to fetch info on the User and Organization.

  • Wow! Fantastic idea. Jason, I really appreciate you taking the time to provide a thoughtful answer. I love this idea. Back to the drawing board... Cheers. Oct 27, 2014 at 21:52

You must log in to answer this question.

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