Having some trouble as an ISV with dynamic SOSL. I have a search box that searches all records. When building the SOSL query, I only add objects that have the IsSearchable flag set to true on the EntityDefinition table. I also exclude objects from packages who have an expired namespace, and packages which require a license, but the running user is not licensed for. However, even with those precautions, I still get a lot of objects back which throw an error in a SOSL query saying “sObject type ‘xxx’ 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.“.

They have been mostly standard objects up until now, such as AuthorizationFormConsent, SocialPersona, CaseExternalDocument, and others. I have filtered them out manually, and moved on. But now I am starting to get custom objects that are:

  • Marked searchable on the Object setup page
  • Marked IsSearchable = true on the EntityDefinition table
  • From packages that are not expired
  • From packages that don’t require licenses

And those objects are still not supported for SOSL. So my questions are:

  • Am I misunderstanding that IsSearchable means that it is supported for SOSL?
  • Could there be any other reasons why a person who has read access to an object, which is a part of an unexpired and unlimited license managed package would not be able to perform a SOSL search on that object?
  • Do you have a more reliable way fo telling if an object is supported by SOSL?

Wanted to edit after I've learned some things today:

The IsSearchable flag on EntityDefinition does indeed mean that the object can be searched in SOSL. If you try to run a SOSL query on an object that has the IsSearchable flag marked false, you will get a different error message that says: "entity type xxxx does not support search".

Past that, the only reasons that a user would not be able to run a SOSL query on an object is if they do not have access to that object for some reason. That is what the error message above means.

Regarding the User having access, the reasons I am currently checking for include:

  • User has IsReadable = true in the UserEntityAccess table
  • The package that the Object is a part of is not expired
  • If the package license has a number of seats, the User has one of those seats

Even with checking for those things, as I stated above, I found some objects that I was not able to run a SOSL query on in Apex.

However, I did find (praise be to sfdcfox) that running the query that adheres to the above specifications through the REST API ran successfully. So, similar to how the REST Tooling API has some fields that the Apex queryable Tooling API does not, it seems that the SOSL Search through the REST API is more reliable than the Apex Search.query() method.

  • I know this doesn't answer your question but I'm curious, why do you need a search that can search across every single searchable object? Wouldn't it be easier to specify which objects are supported by whatever your app does? Jul 11, 2019 at 18:10
  • Did you consider queryable attribute instead of searchable? This looks more of an attribute specifying whether the object could be used in a query() call and hence SOSL and SOQL. Jul 11, 2019 at 18:12
  • @CommonCoreTawan Definitely, however, the app needs to search all objects which could technically be permissionable. As in you could go into a profile, and find the object in the Object Settings section for either standard or custom objects. So in conjunction with the search for IsSearchable, I also require objects to have IsFlsEnabled set to true. But there isn't really a hard list I would be able to set. It is pretty fluid from org to org depending on the features in the org. Jul 11, 2019 at 18:17
  • @ShaileshPatil I did not try queryable because I thought that was for SOQL, trying that now, thanks! Edit: looks like I do get the same thing from IsQueryable, says a particular object is, however I am getting an error when trying to SOSL search on that object. Jul 11, 2019 at 18:19
  • Can you/would you want to use an API call, or are you insisting it be done in Apex with a dynamic SOSL call?
    – sfdcfox
    Jul 11, 2019 at 18:53

1 Answer 1


Assuming everything is set up correctly, you can use this simple API call:

String searchTerm = 'demo';
HttpRequest req = new HttpRequest();
req.setHeader('Authorization','Bearer '+UserInfo.getSessionId());
String searchResultsAsJson = new http().send(req).getBody();

Here, we use the REST Search API call to search all available objects for matching terms. This will automatically restrict the search to just objects the user can search and those that are searchable.

As far as why isSearchable is causing errors for objects the user has access to but SOSL refuses to search on, I'd recommend logging a bug with Support.

  • I like this, however, I unfortunately need the name of the record too. So before this I was getting all the objects I wanted to search through SOSL, and then querying the FieldDefinition table to find the name field, then I would construct the SOSL query returning Id and the Name field for that object. Although I suppose I can then query out the name field and the name separately after that. Jul 11, 2019 at 20:51
  • WOAH ok, when I run the query string I generated in through the api, it actually does not give me the same error as I get when running it through Apex. We have a winner I believe! Although I can't explain why, the REST API works as you would expect, and the Apex version is broken. You have saved the day once again, sfdcfox. Jul 11, 2019 at 20:59
  • 1
    @TobyCurtis Yeah, you might want to contact support regarding that. The API call is simple enough, though.
    – sfdcfox
    Jul 11, 2019 at 21:45

You must log in to answer this question.

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