Is there a reliable way to know which SObjects are supported by a SOSL search?

Question

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.

Answer 1

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

String searchTerm = 'demo';
HttpRequest req = new HttpRequest();
req.setEndpoint(System.url.getSalesforceBaseUrl().toExternalForm()+
    '/services/data/v45.0/search?q=find+{'+searchTerm+'}+in+all+fields');
req.setMethod('GET');
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.