When I query SymbolTable using Tooling API there are not any protected modifiers at all! Every protected word is replaced with private. The field classBody shows all protected keywords as they are but SymbolTable doesn't show any of them.

What is the reason for that? Is that a bug or it has some sense?

  • Have you logged a case with Salesforce Support?
    – Marty C.
    Dec 9, 2014 at 22:32
  • I can't open an issue because I have only developer edition account. Or do you mean something else? I would like to do something like that but don't know how. Dec 9, 2014 at 22:35
  • No, you're right. If you're not a Salesforce customer or partner, I don't think you'll be able to log a case. :-(
    – Marty C.
    Dec 9, 2014 at 23:19
  • Even if you are a partner but without premier support, they close the case if it's related to development. Sounds like a bug. Would be great if someone with PS could report it.
    – Uwe Heim
    Dec 10, 2014 at 9:54
  • I see you've raised the question on the developer forums. I've found support will usually get back to you in a week (or month...). It is a frustratingly slow way to raise a platform bug/issue, but it usually pays off if you are persistent. Dec 18, 2014 at 7:28

1 Answer 1


Update from Salesforce support:

I checked with R&D regarding this, and they are releasing an enhancement to allow all modifiers in the next version of the API, which is 34 (Summer '15). -Shashank

It appears that at the API level protected isn't supported.

Extract from the Tooling API v32.0 WSDL:

<xsd:simpleType name="SymbolVisibility">
 <xsd:restriction base="xsd:string">
  <xsd:enumeration value="Global"/>
  <xsd:enumeration value="Public"/>
  <xsd:enumeration value="Private"/>

Note the absence of protected. It can't be returned, so it appears they send back private instead.

You also see hints of this in the documentation for SymbolTable:

SymbolTable visibility options

It does seem odd the protected isn't represented, as it is valid in Apex access modifier.

  • Yeah I noticed this part in documentation later. Either it's odd or it has some meaning that we don't understand. Dec 17, 2014 at 23:40
  • I suspect it will take someone inside Salesforce to answer the why of it. A couple of guesses: 1) They based the API on what access modifiers were allowed for a constructor and did a hack work around for protected properties rather than add in protected. 2) protected access modifiers have some sort of odd internal representation that gets lost in the transition to a SymbolTable. Dec 18, 2014 at 7:21
  • I work at Salesforce and can look into this. Curious to know myself. Querying ApexClass is a possible workaround, but requires parsing the Body: SELECT Id, Name, Body FROM ApexClass
    – dlog
    Dec 31, 2014 at 5:49
  • @dlog Thanks, I'd be interested to know what comes of it. Dec 31, 2014 at 8:24

You must log in to answer this question.

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