I'm using the Tooling API to dynamically create an Apex Trigger. The trigger itself consists of one line, calling a method in a Util class.

Creating this trigger by hand works fine.

When I try to create the trigger using the Tooling API, Salesforce tries to recompile the Util class (not sure why it needs to do this). During the recompile of the Util class, it stumbles across this line in the Util class:

    List<User> admins = [Select Email from User where ProfileID = :profiles[0].id];

The entire response from the Tooling API is:

[{"message":"Dependent class is invalid and needs recompilation:\nutil: line 614, column 23: No such column 'Email' on entity 'User'. If you are attempting to use a custom field, be sure to append the '__c' after the custom field name. Please reference your WSDL or the describe call for the appropriate names.","errorCode":"INVALID_FIELD_FOR_INSERT_UPDATE","fields":[]}

I've verified that this is indeed the problematic line. If I comment out the entire method that has the "Select Email from User ..." in in (and some other similar problems), the Metadata API call succeeds, and the trigger is created.

I'm really baffled why Salesforce would think that Email is not a field on User and would be glad for any suggestions. There are other parts to this (Salesforce also claims that ParentID is not a field on the FieldPermissions object, etc), so unfortunately just doing a database.query instead (which seems to work) isn't an option.

I'm thinking it has to do with the fact that the code to create the trigger is called asynchronously from another trigger, with the SessionId passed through. OTOH, the trigger is created fine with the offending code commented out, so API access as well as Author Apex permissions clearly come through.

  • 2
    I've solved the problem for now by putting all User related things into a class that is not referenced indirectly by the trigger creation. It seems like it's a make issue, where the make doesn't think it will need User but then finds that it does after all. Still, any pointers how to generally avoid the situation are requested. I've had to restructure our package several times and, of course, this issue is never encountered on a slow day. – Jochen Nov 18 '16 at 19:34
  • I have benn spoted by this bug sometimes as well, for me always helpfull was deploy all metadata from repo using antDepolyCode~~ which obviously uses MD Api. After that deploy by tooling api works again. – patryk Oct 4 '17 at 11:24
  • 1
    Follow up: Similar behavior in other areas leads me to think that there could be a bug in the Apex optimizer. Reshuffling code is usually sufficient to make it go away. In particular, copying the code directly into the class avoids the issue as well. One example was code in a PostInstall class calling routines in a helper class. Moving the routines directly into the PostInstall class solved the issue. – Jochen Jan 11 '18 at 22:00

Your Answer

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

Browse other questions tagged or ask your own question.