5

I'm working on a managed package that will allow users to select an object in their org and create a mapping with an external service. I noticed that Schema.getGlobalDescribe() returns a plethora of objects of likely very little interest for our use case (e.g. objects describing sharing, roles, platform objects).

I peeked around at some packaged code and found that a common filter for objects to display is isCreateable() && isUpdateable() after getting the global describe. In my dev org this returns 191 objects. If I filter it a bit further to remove any object ending with Share or Role, I'm down to 155. Still a lot of stuff users won't care about for our use case though. I cross-referenced with a query on EntityDefinition where isLayoutable = true and got the list down to 110. I still end up with a lot of "Special" standard SObjects like AssetRelationship, CollaborationGroup, DuplicateRecordItem that are exceedingly unlikely to fit the use case.

I'm being a little vague here on what really should constitute a "first-class" object because maybe I don't even know what to look for, but does anyone have any ideas on what you'd usually filter by to ensure you only return "important" standard SObjects (and all custom ones because we can't judge) for the user to select from?

  • Alternate solution: use Custom Metadata and Lookup(Entity Definition). Users define records for the objects they're interested in and then your app only shows those objects as options to configure. I think Entity Definition only shows the types of sObjects you're interested in. – Mike Chale Jan 26 '18 at 14:27
  • 1
    One step ahead of ya, already planning to use Custom Metadata with lookup to EntityDefinition. I see that right now when creating a mdt record I get a list of 86 objects. However we do plan to have a custom setup UI because after associating the mapping object they'll also be selecting many fields to be part of the mapping, and we want it to be user-friendly enough. When I actually query EntityDefinition to find the options though I get way more than those 86. – Charles T Jan 26 '18 at 18:06
4

Depending on your specific use case, I would most likely go with isMruEnabled || isCustom. isMruEnabled returns true for things that have a Tab (e.g. Accounts will return true, but AccountShare will return false). Since custom objects may or may not have a Tab, and having a Tab is one of the requirements for isMruEnabled, you'd want to grab anything that's custom, just to be on the safe side. Oddly, AssetRelationship still returns true, but DuplicateRecordItem does not; whatever is controlling isMruEnabled is probably looking at other things as well besides just having a Tab, but it's not clearly documented what situations can cause this.

| improve this answer | |
  • Thanks, sounds like a viable plan. That actually makes me think, maybe it would be a good idea to promote to the top of the list any object that is a tab for any of the apps in the org. – Charles T Jan 26 '18 at 12:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.