0

It looks as if a field called "SourceId" suddenly showed up in my org, on the Case object. Previously, I had taken all of my org's metadata, and placed it into TFS (Team Foundation Server), as part of a continuous integration process. The CI server pushes updates from TFS to our partial sandbox.

The build is broken now, and I cannot deploy with Ant. Here is the error message:

  1. profiles/Admin.profile -- Error: In field: field - no CustomField named Case.SourceId found

Sure enough, the following section is in my Case metadata now, but does not appear in TFS (the previous version of metadata):

<fields>
    <fullName>SourceId</fullName>
    <trackFeedHistory>false</trackFeedHistory>
    <trackHistory>false</trackHistory>
    <trackTrending>false</trackTrending>
    <type>Lookup</type>
</fields>

This field is not visible in the UI, and there appears to be no way to deploy this change to our partial sandbox. Interestingly, both my developer sandbox and partial sandbox were on CS11, and have been upgraded to Winter 16. If this SourceId field was going to appear in my developer org, why didn't it appear in the partial environment?

There are numerous other strange messages, such as:

objects/Case.object -- Error: No more than 10 columns may be specified in lookupPhoneDialogsAdditionalFields (line 65628, column 20)

and:

objects/Contact.object -- Error: AddContact is not a standard action and cannot be overridden.

What even?

  • 1
    (line 65628, column 20) That's just terrifying. Why would a class ever have 65k lines? – Adrian Larson Sep 17 '15 at 19:47
  • 1
    It's an object. In this instance, the error is about the Case object. The XML metadata is around 66,000 lines. – Pittsburgh DBA Sep 17 '15 at 20:48
  • Ah that makes more sense. – Adrian Larson Sep 17 '15 at 20:48
  • I ran into this issue today as well. We're going to open a case with SFDC since this definitely seems like an issue on their end. Doing a retrieve call returns this field in the case metadata and deploying it back to the same org gives this error. – jwolf Sep 28 '15 at 15:57
3

This is actually a known issue. SFDC will be releasing a patch for this soon - https://success.salesforce.com/issues_view?id=a1p300000001ALuAAM

4

I had the same issue today and I believe it is a new standard field added by the Winter 16 release. The target sandbox is certainly not up to date (to confirm) so this field is then interpreted as a custom field that does not match the naming conventions (custom fields must end with: __c or __kav or __x or __xo or __mdt).

Just remove the field from the Case object, and from all the profiles and permission sets in your metadata files and Ant should then work just fine.

The reason why this field is not visible in the list of fields for the Case object in Salesforce is beyond my understanding.

  • Thank you for validating this weirdness! The issue is that I cannot see the field in the Salesforce UI or Setup, but it appears in the metadata. This org has over 70 profiles, so I am loathe to try and edit the XML manually at this point. We are contemplating opening a support case, because the target org is on Winter 16, but does not have this field in its metadata. – Pittsburgh DBA Sep 18 '15 at 14:03
  • Hi Pittsburgh DBA, you don't need to manually edit xml for all 70 profiles. You could just add a regexp to your ant build target in the build.xml and define a fileset (which would in your case be *.profile :) ) on which to perform the replacement of xml node fieldPermission-for-field-Case.SourceId with empty string. PS. please drop a comment if you manage to debug AddContact action, as I'm currently struggling with that one. – dino ursic Sep 24 '15 at 16:17
0

I had this same problem : objects/Contact.object -- Error: AddContact is not a standard action and cannot be overridden.

This happened after our environments upgraded to the Winter '16 release.

To remedy the issue, I refreshed the Contact object from the sandbox, then I deployed the Contact object with the other metadata. We use mavensmate with sublime text 3 and bamboo for deployments.

  • Thank you. We ended up doing pretty much the same thing. The other issues we were experiencing were patched by a Salesforce update. – Pittsburgh DBA Oct 20 '15 at 18:13

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.