I have a global class in a managed package like this:

global with sharing class MyClass {
     * class members, constructors, methods, etc

    public List<Lead> getRecentlyViewedLeads () {
        List<RecentlyViewed> viewed = [SELECT Id FROM RecentlyViewed WHERE Type = 'Lead' LIMIT 20];
        List<Contact> contacts = new List<Contact>();
        for (RecentlyViewed view : viewed) {
            contacts.add(new Contact(Id = view.Id));
        return contacts;

It is more complicated than that, but this should be sufficient to demonstrate the issue. When one of my customers updates objects in Salesforce and runs their unit tests, they see compilation errors and unit test errors in their code, until they recompile my managed package. The errors are all look similar to:

line -1, column -1: Previous load of class failed: MYPACKAGE.MyClass: line XXX, column YY: sObject type 'RecentlyViewed' is not supported. If you are attempting to use a custom object, be sure to append the '__c' after the entity name. Please reference your WSDL or the describe call for the appropriate names.

The details of the inheritance chain can change from error to error (it sometimes starts from a class that inherits from MyClass), but they all reference the same line selecting from the RecentlyViewed object in MyClass.getRecentlyViewedLeads.

While this class is global, the customer claims not to be referencing it in their code. The customer pushes code changes to their Salesforce sandbox on a daily basis, and gets these errors every single time. Recompiling my managed package after pushing their code changes resolves the problem and allows their unit tests to pass.

I would normally associate that error with a permissions problem (where the user running the code cannot see the RecentlyViewed object), but since the problem disappears after recompilation, I feel that this is unlikely to be correct.

What I would like to know is:

  • could this be as simple as a permissions issue?
  • would changes to standard objects (Contacts, Leads, etc) propagate to the RecentlyViewed object, requiring my managed package to be recompiled to take them into account?
  • is there some other issue that might cause the RecentlyViewed object to behave this way?
  • why might a customer's own code care whether there were compilation issues in an installed managed package, if it never references anything in that managed package?
  • What do you mean by "Recompiling my managed package"? Are you using the "Compile all classes" link on the Apex Classes page? Nov 30, 2015 at 22:38
  • Do any of their classes have an apiVersion or version setting dependency to a version of your managed package that preceded the definition of RecentlyViewed in Summer `13? (earlier than v28.0) Nov 30, 2015 at 22:43
  • @DanielBallinger, yes, the customer is using the "compile all classes" link. Some of their classes use API version 27 or older, but others on higher API versions fail with the same error.
    – asgallant
    Nov 30, 2015 at 23:10

1 Answer 1


sObject type 'RecentlyViewed' is not supported

This makes me think it is strongly related to the API versions. It's exactly the sort of message you would get when trying to save an Apex class when RecentlyViewed wasn't available yet. RecentlyViewed came out in Summer '13 (API v28.0). However, the are indications in the online documentation that it was valid in v27.0. From NetworkId field:

You can add a NetworkId only when creating a group. You can’t change or add a NetworkId for an existing group. This field is available in API version 27.0 and later.

You mention other apex classes with higher API numbers (v32.0) still failing, but I suspect it is a cascading/dependency problem ultimately.

I think the org starts out in a state where it can draw a dependency from your Managed Package MyClass back to the class that is being updated. Somewhere in that mix is an Apex class or trigger with a version insufficent to access RecentlyViewed. The stacktrace in the errors might better highlight what that path looks like.

That said, I can't easily explain why compiling all the Apex classes helps. I suspect that the recompile forces Salesforce to rebuild the dependencies. This removes the dependency check back to the managed package class and it doesn't get recreated. Hence the classes can be saved again.

If at some point in the future the dependency to the managed package gets picked up again in Salesforce then things will start failing again.

Untangling this could be a big job. You would need to identify when the problematic dependency gets recreated. The SymbolTable might be useful here. There could be other factors here, such as how the Apex classes/triggers are being edited and deployed (Metadata API/Tooling API, etc..)

It might not be a popular option, but try updating ALL components to an API version that supports RecentlyViewed.

  • 1
    Turns out there is an internal bug in Salesforce that is causing the isValid flag on my classes that reference RecentlyViewed to be flipped off when the customer pushes updates to their classes on old API versions. Salesforce recommends having the customer update their classes to v28 or higher.
    – asgallant
    Dec 1, 2015 at 22:32

You must log in to answer this question.

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