Standard Fields Not Listed Under the "CustomField" Metadata Type

Issue #670 resolved
Daniel C. created an issue

In order to deploy standard fields like changes to standard picklist values, the standard fields were supposed to be available under "CustomField" metadata type. This was supposed to be fixed under a previous update but now it seems it's no longer available.

From Scott's comments, it seems to be a regression issue. For follow-up details, see the following comment: https://groups.google.com/a/illuminatedcloud.com/forum/#!topic/qanda/QQuRgGxKSjo

Comments (3)

  1. Scott Wells repo owner

    Daniel, it actually turns out this is not a regression. When I addressed this before, it was actually for another use case. Today I dove into this and found that standard fields are not included in the response to the metadata API's listMetadata('CustomField'). Only standard fields are included. The only way to list standard fields is to use the partner API's describeGlobal() followed by a series of describeSObjects() for batches of SObject type names. This can tend to add a non-trivial amount of time to the sometimes already expensive operation of listing all metadata in the org, and when you include standard fields in the subscription editor, it becomes VERY cluttered.

    I then realized that with more recent versions of the API (38.0+, I think), you can manage picklists separate from fields via the StandardValueSet and GlobalValueSet metadata types. For example, I pulled the LeadSource standard value set which is used to managed Account.AccountSource and was able to fully manage the values for that field without having to pull down the field explicitly. In fact, when the field is retrieved, it doesn't even include the picklist values for management.

    I don't know if you're working against an older version of the API, but if so would updating to an newer version that supports value sets be an option? To be honest I'm very hesitant to make a change that negatively impacts all users in terms of both performance and clutter in the UI, especially when another platform-supported option is available.

    Please let me know your thoughts. For now I'm going to shelve these changes so they won't be included in the 1.7.9.8 build.

  2. Scott Wells repo owner

    Daniel, I'm going to resolve this for now hoping that the other metadata types allow you to solve the same problem, but if that doesn't do it for you, please feel free to reopen with some detail on why.

  3. Log in to comment