Can a managed package safely access custom objects that are not part of the package using dynamic Apex?

Question

There seems to be a documentation inconsistency.

The Apex developer guide, in the section on "Understanding Describe Information Permissions" https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_dynamic_permissions.htm says:

While Partners can request access to standard objects, custom objects are not included as part of the managed package and can never be referenced or accessed by dynamic Apex that is packaged.

Suggesting that managed packages cannot access these custom objects

Meanwhile, the ISV force guide, in the section "About API and Dynamic Apex Access in Packages" https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/about_client_security_profile.htm says of the unrestricted API package setting:

The default Unrestricted, which gives the package components the same API access to standard objects as the user who is logged in when the component sends a request to the API. Apex runs in system mode. Unrestricted access gives Apex read access to all standard and custom objects

Suggesting that managed packages can access these custom objects.

Meanwhile, the whole concept of restricted and unrestricted seems to have been deprecated as of Summer 16 as described in this knowledge base article: https://help.salesforce.com/articleView?id=000239703&type=1 that says:

It has been identified that access settings behind the API Access attribute are only applicable if your organization has a legacy org feature enabled that has now been deprecated. The majority of customers do not have this mentioned feature enabled for their org and it may not be turned on moving forward.

In my own tests, I'm finding that managed packages CAN access custom objects that are not part of the package using dynamic Apex. In the past I was not unable to do so (I don't recall when), so my working theory is that something has changed and that the Apex language reference is now incorrect. I have not tested it in an AppExchange package though - only in released managed packages that are not published to the AppExchange, though it seems highly unlikely that a restriction would be based on that fact.

So - does anyone have any insight or information to clarify the following:

1. Is it, in fact, now possible to safely use dynamic Apex in managed packages (Appexchange or other) as long as it is not a legacy "Restricted" application.

2. If so, does this actually represent a change in behavior and do we have any idea when that change took place?

Answer 1

It is, in general, definitely possible to execute dynamic Apex against unmanaged custom objects, although there are currently a few cases where it doesn't work (for example, if an unmanaged object has the same developer name as an object in your package, a dynamic query will always choose the object in your package).

The ability to set packages "Restricted" doesn't depend on the package, but rather on the subscriber organization. So even if you create a new package, it is possible that an old organization could install it and set it as restricted. But that's their choice; you can always mention in the application description that the application won't work if they do so.

I wouldn't want to guarantee that every use of dynamic apex to access unmanaged objects will pass security review; my guess is that the security team might want to see good reason. But I do believe there are some approved AppExchange packages that do this.