5

When developing a Managed Package, should I be careful when designing and creating objects in order to try and make them Light Application objects if that is possible?

Will the end users of the managed package get any benefits if at least some of the objects I deploy in my package are Light?

Finally, will I be able to change my mind in the future versions of the managed package?

enter image description here

  • 1
    Awesome question. Led me to look up this one from which I conclude your package would be compatible with the Force.com Light App License, though users with that license might still be restricted from using your package if they already have 10+ Light Application Objects, or if critical objects in your package depend on others which you have not configured in this way. I'm no expert though, hence comment instead of answer. – Adrian Larson Apr 26 '17 at 21:16
1

I think the answer to this question depends entirely on the nature of the application that you're creating. If, for example, your objects are only used internally by your application and don't need to be shared or wouldn't have data imported to them via data loader or ETL tools (either directly or indirectly), then it seems that you wouldn't need, and perhaps might not want, to enable that kind of access.

Now, here's where it gets tricky. Can you envision situations where in order to access one of your object's records, a 2nd object's related records would need to be shared? Are your objects visible to your users? If not, those objects would seem to be likely candidates for Light Objects.

If your objects are visible, then your enterprise clients will likely want/need the ability to share records and have access to the Bulk API. If anything, they'll want the latter at a minimum for data export/import as part of back-ups and restores. Does your application have potential use where a customer might want to send or receive streaming updates? That's difficult to predict isn't it? Would you want a customer to be upset because they couldn't? Again, I think that decision largely depends on the nature of your application along with the kind of data your application's objects will hold, plus whether they're exposed for direct consumption by your customer.

One of the interesting things I found in the Help is that if one of the settings is enabled to make a Light Object an Enterprise Object, ALL of the settings must be enabled.

Allow Sharing

When this setting is enabled, the custom object is an Enterprise Application object. When this setting isn’t enabled, the custom object is a Light Application object.

When this setting is enabled, you must also enable Allow Bulk API Access and Allow Streaming API Access.

Allow Bulk API Access

When this setting is enabled, the custom object is an Enterprise Application object. When this setting isn’t enabled, the custom object is a Light Application object.

When this setting is enabled, you must also enable Allow Sharing and Allow Streaming API Access.

Allow Streaming API Access

When this setting is enabled, the custom object is an Enterprise Application object. When this setting isn’t enabled, the custom object is a Light Application object.

When this setting is enabled, you must also enable Allow Bulk API Access and Allow Sharing.

In Enhance your Sales Cloud Implementation, I found the following reference:

By default, all custom objects are Enterprise Application objects.

As for "will I be able to change my mind in future versions of your managed package?" I strongly suspect the answer is that you'll encounter issues for customers who are upgrading/updating their existing packages from light objects to enterprise objects which is something you'd need to test. I suspect that you'd be able to find a way to change the objects from Light to Enterprise, but the upgrade might impact data in orgs who currently have your package installed; potentially causing data loss if it's not first backed-up and then restored afterward.

Here's a link to an answer with comments below it by @ScottCovert that links to the following SF Managed Package Name Change Hack screen cast that may be of interest. It suggests there are things one can do, which perhaps aren't officially allowed (for good reason), that could have consequences for customers upgrading their package from one version to the next.

  • Considering the idea behind the package I'm creating, I think that this answer has given me more than enough reasons not to go down the path of Light Application objects. I think that if I were to go down this path I would have to impose probably unnecessary limitations both upon the package and its end users. Thank you for your advice. – smukov Apr 27 '17 at 16:00

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.