function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
Steve McConnellSteve McConnell 

Field-Level Security changes in API 30 -- how to address?

As of API30 update, we no longer have visibility on CustomFields that are created using the Metadata API. Looking at the Metadata API Developer's Guide v30.0 for ProfileFieldLevelSecurity, this seems to be an intentional change for API30: new CustomFields have their 'readable' flag set to false by default.

This is causing an issue when we attempt to list the fields for the related object: the new CustomFields are not returned as part of the DescribeSObjectResult data, as they are now defaulting to being hidden for all profiles.

This impacts our testing / QA environments, as they need to create new objects/fields and access them programmatically.

Is there a simple mechanism for forcing the new CustomField(s) to be flagged as visible, either for all profiles or for the current profile, when creating the field(s)?

What is the most efficient way to make CustomFields be visible when creating them?
Lee WonLee Won
Steve: did you ever find an answer to this. I am struggling with the same issue.
Steve McConnellSteve McConnell
No answer yet from Salesforce, so we have been using a workaround:  after creating the custom fields, manually change their Field-Level Security settings in the desired Profiles to make them visible.  We do this via the Metadata API; we use the synchronous versions, as the async versions no longer operate correctly after API 31 was rolled out (https://developer.salesforce.com/forums/ForumsMain?id=906F0000000AcQvIAK).

For general behavior with the adjusted profiles, this workaround allows for basic operation.  However, there are still areas where it is problematic, such as with Database.com servers:
https://developer.salesforce.com/forums/ForumsMain?id=906F0000000Aff6IAC

Hope that helps.