Blog

Dynamic Apex, introduced in the Summer 08 release of Salesforce‘s Apex programming language, allows developers to create more flexible applications by providing them with the ability to access object and field information as well as write dynamic SOQL queries.  Unfortunately there is a rather annoying aspect of Dynamic Apex that hamstrings the application the second it is put into a managed package.  Anyone who has been working with this feature of Apex knows the frustration of seeing their working application reduced to a garbled pile of Unit Test failures and cryptic Query Exceptions informing you that something ”is not accessible in query due to package restrictions.” Luckily, there is a work around… kind of.

The reason these errors occur is because, simply put, once the application is packaged it only has access to its own custom classes.  To confuse matters even more, the default API Access for a new package is Unrestricted.  Now call me simple, but IMHO that would imply that there are no restrictions.  Unfortunately that is not the case.  Access to standard objects, such as the all important Lead object, is restricted by default.  To allow access, you must first enable restrictions, and then specifically allow access to each standard object that you want to interact with.

Not very intuitive, I know.  In fact, it is more or less backwards.  But it works, and apparently it is working in the way that Salesforce developers intended…