16

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.

4
  • 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, 2016 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, 2017 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, 2018 at 22:00
  • Surprisingly, this behavior is still there. I tried to recreate the same but got similar error. I tried with rest version of tooling API.
    – Ysr Shk
    Jul 10, 2020 at 17:03

1 Answer 1

-1

Right now the Tooling API doesn't support some things. Please use Metadata API.

2
  • 1
    Please elaborate on your answer to explain and possibly give a code snippet or example of how what the OP is wanting to do can be achieved via Metadata API.
    – Moonpie
    Sep 20, 2021 at 17:37
  • That wasn't/isn't the issue. The code was failing before it ever reached the point of doing a callout to the API. It's my guess based on the workaround I described above that the optimizer was overly zealous, putting the same code into a different class worked.
    – Jochen
    Sep 21, 2021 at 19:10

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.