In order to succesfully create new objects and fields and configure their visibility, we use the Metadata API's synchronous CRUD operations, which were added in API 30 and API 31.

This works successfully for Salesforce.com instances, but does not behave as expected for Database.com instances; we are seeing the following SOAP fault when attempting to call readMetadata():
INSUFFICIENT_ACCESS: insufficient access rights on cross-reference id

This is impacting our ability to manage our objects and fields via the API, which is necessary for our testing / QA to programmatically perform their tasks.


From the API documentation, the synchronous metadata operations require the "Modify All Data" permission.  For the Salesforce.com instances, this is present for the primary user (which uses the "System Administrator" profile) and everything works as expected.

For the Database.com instances, the user (which uses the "Database.com Admin User" profile) does not have the "Modify All Data" permission.  However, the createMetadata() and deleteMetadata() calls work anyway.

It seems that Database.com uses some custom logic to allow access for certain metadata operations, without having the "Modify All Data" permission.  This was probably in place with the original asynchronous calls:  create(), update(), delete().  I suspect this custom logic was applied when the synchronous versions were added as createMetadata(), updateMetadata(), and deleteMetadata(); that would explain why they continue to work as expected for Database.com.

If this is the case, the solution is for Database.com servers to enable access with the other synchronous CRUD-based metadata calls just like what has been done for the above methods.  The list of other calls is:
readMetadata()
upsertMetadata()
renameMetadata().

If the above guesses are not correct:  how should we address this issue?



For reference, here is the SOAP request body (header trimmed) that was sent to a Database.com server:
<soap:Body>
        <readMetadata xmlns="http://soap.sforce.com/2006/04/metadata">
            <type>Profile</type>
            <fullNames>SolutionManager</fullNames>
            <fullNames>Admin</fullNames>
            <fullNames>MarketingProfile</fullNames>
            <fullNames>ContractManager</fullNames>
            <fullNames>ReadOnly</fullNames>
            <fullNames>Database%2Ecom User</fullNames>
            <fullNames>Database%2Ecom Admin User</fullNames>
            <fullNames>Standard</fullNames>
        </readMetadata>
    </soap:Body>



Here is the full SOAP response to the above request:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:sf="http://soap.sforce.com/2006/04/metadata">
    <soapenv:Body>
        <soapenv:Fault>
            <faultcode>sf:INSUFFICIENT_ACCESS</faultcode>
            <faultstring>INSUFFICIENT_ACCESS: insufficient access rights on cross-reference id</faultstring>
        </soapenv:Fault>
    </soapenv:Body>
</soapenv:Envelope>

We first create a new object GTABLE_SM2__c via the asynchronous create() metadata call.   Then we attempt to add multiple fields to this object via another create() call.

Prior to the Summer '14 update for the organization's server, this was performed without issue.   Following the Summer '14 update, this create() call fails if the number of fields is greater than 6.  The SOAP fault is "UNKNOWN_EXCEPTION: Async job could not be executed".

If the create() is performed for 6 or fewer fields on this object, then it succeeds.

This behavior has been observed for both API 29 and API 30 endpoints.

We observed this across multiple Salesforce servers, and noticed that as Summer '14 was rolled out to a server, the behavior of its organizations began showing this problem.


Sample SOAP log of the create() data for 7 fields (header trimmed):

<soap:Body>
    <create xmlns="http://soap.sforce.com/2006/04/metadata">
        <metadata xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CustomField">
            <fullName>GTABLE_SM2__c.COLA__c</fullName>
            <label>COLA</label>
            <precision>18</precision>
            <scale>0</scale>
            <type>Number</type>
        </metadata>
        <metadata xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CustomField">
            <fullName>GTABLE_SM2__c.COLB__c</fullName>
            <label>COLB</label>
            <length>80</length>
            <type>Text</type>
        </metadata>
        <metadata xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CustomField">
            <fullName>GTABLE_SM2__c.COLC__c</fullName>
            <defaultValue>false</defaultValue>
            <label>COLC</label>
            <type>Checkbox</type>
        </metadata>
        <metadata xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CustomField">
            <fullName>GTABLE_SM2__c.COLD__c</fullName>
            <label>COLD</label>
            <type>Date</type>
        </metadata>
        <metadata xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CustomField">
            <fullName>GTABLE_SM2__c.COLE__c</fullName>
            <label>COLE</label>
            <length>5</length>
            <type>Text</type>
        </metadata>
        <metadata xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CustomField">
            <fullName>GTABLE_SM2__c.COLF__c</fullName>
            <label>COLF</label>
            <precision>18</precision>
            <scale>9</scale>
            <type>Number</type>
        </metadata>
        <metadata xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CustomField">
            <fullName>GTABLE_SM2__c.COLG__c</fullName>
            <defaultValue>false</defaultValue>
            <label>COLG</label>
            <type>Checkbox</type>
        </metadata>
    </create>
</soap:Body>



The full response message:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:sf="http://soap.sforce.com/2006/04/metadata">
    <soapenv:Body>
        <soapenv:Fault>
            <faultcode>sf:UNKNOWN_EXCEPTION</faultcode>
            <faultstring>UNKNOWN_EXCEPTION: Async job could not be executed</faultstring>
        </soapenv:Fault>
    </soapenv:Body>
</soapenv:Envelope>

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?

We first create a new object GTABLE_SM2__c via the asynchronous create() metadata call.   Then we attempt to add multiple fields to this object via another create() call.

Prior to the Summer '14 update for the organization's server, this was performed without issue.   Following the Summer '14 update, this create() call fails if the number of fields is greater than 6.  The SOAP fault is "UNKNOWN_EXCEPTION: Async job could not be executed".

If the create() is performed for 6 or fewer fields on this object, then it succeeds.

This behavior has been observed for both API 29 and API 30 endpoints.

We observed this across multiple Salesforce servers, and noticed that as Summer '14 was rolled out to a server, the behavior of its organizations began showing this problem.


Sample SOAP log of the create() data for 7 fields (header trimmed):

<soap:Body>
    <create xmlns="http://soap.sforce.com/2006/04/metadata">
        <metadata xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CustomField">
            <fullName>GTABLE_SM2__c.COLA__c</fullName>
            <label>COLA</label>
            <precision>18</precision>
            <scale>0</scale>
            <type>Number</type>
        </metadata>
        <metadata xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CustomField">
            <fullName>GTABLE_SM2__c.COLB__c</fullName>
            <label>COLB</label>
            <length>80</length>
            <type>Text</type>
        </metadata>
        <metadata xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CustomField">
            <fullName>GTABLE_SM2__c.COLC__c</fullName>
            <defaultValue>false</defaultValue>
            <label>COLC</label>
            <type>Checkbox</type>
        </metadata>
        <metadata xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CustomField">
            <fullName>GTABLE_SM2__c.COLD__c</fullName>
            <label>COLD</label>
            <type>Date</type>
        </metadata>
        <metadata xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CustomField">
            <fullName>GTABLE_SM2__c.COLE__c</fullName>
            <label>COLE</label>
            <length>5</length>
            <type>Text</type>
        </metadata>
        <metadata xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CustomField">
            <fullName>GTABLE_SM2__c.COLF__c</fullName>
            <label>COLF</label>
            <precision>18</precision>
            <scale>9</scale>
            <type>Number</type>
        </metadata>
        <metadata xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CustomField">
            <fullName>GTABLE_SM2__c.COLG__c</fullName>
            <defaultValue>false</defaultValue>
            <label>COLG</label>
            <type>Checkbox</type>
        </metadata>
    </create>
</soap:Body>



The full response message:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:sf="http://soap.sforce.com/2006/04/metadata">
    <soapenv:Body>
        <soapenv:Fault>
            <faultcode>sf:UNKNOWN_EXCEPTION</faultcode>
            <faultstring>UNKNOWN_EXCEPTION: Async job could not be executed</faultstring>
        </soapenv:Fault>
    </soapenv:Body>
</soapenv:Envelope>

We first create a new object GTABLE_SM2__c via the asynchronous create() metadata call.   Then we attempt to add multiple fields to this object via another create() call.

Prior to the Summer '14 update for the organization's server, this was performed without issue.   Following the Summer '14 update, this create() call fails if the number of fields is greater than 6.  The SOAP fault is "UNKNOWN_EXCEPTION: Async job could not be executed".

If the create() is performed for 6 or fewer fields on this object, then it succeeds.

This behavior has been observed for both API 29 and API 30 endpoints.

We observed this across multiple Salesforce servers, and noticed that as Summer '14 was rolled out to a server, the behavior of its organizations began showing this problem.


Sample SOAP log of the create() data for 7 fields (header trimmed):

<soap:Body>
    <create xmlns="http://soap.sforce.com/2006/04/metadata">
        <metadata xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CustomField">
            <fullName>GTABLE_SM2__c.COLA__c</fullName>
            <label>COLA</label>
            <precision>18</precision>
            <scale>0</scale>
            <type>Number</type>
        </metadata>
        <metadata xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CustomField">
            <fullName>GTABLE_SM2__c.COLB__c</fullName>
            <label>COLB</label>
            <length>80</length>
            <type>Text</type>
        </metadata>
        <metadata xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CustomField">
            <fullName>GTABLE_SM2__c.COLC__c</fullName>
            <defaultValue>false</defaultValue>
            <label>COLC</label>
            <type>Checkbox</type>
        </metadata>
        <metadata xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CustomField">
            <fullName>GTABLE_SM2__c.COLD__c</fullName>
            <label>COLD</label>
            <type>Date</type>
        </metadata>
        <metadata xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CustomField">
            <fullName>GTABLE_SM2__c.COLE__c</fullName>
            <label>COLE</label>
            <length>5</length>
            <type>Text</type>
        </metadata>
        <metadata xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CustomField">
            <fullName>GTABLE_SM2__c.COLF__c</fullName>
            <label>COLF</label>
            <precision>18</precision>
            <scale>9</scale>
            <type>Number</type>
        </metadata>
        <metadata xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CustomField">
            <fullName>GTABLE_SM2__c.COLG__c</fullName>
            <defaultValue>false</defaultValue>
            <label>COLG</label>
            <type>Checkbox</type>
        </metadata>
    </create>
</soap:Body>



The full response message:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:sf="http://soap.sforce.com/2006/04/metadata">
    <soapenv:Body>
        <soapenv:Fault>
            <faultcode>sf:UNKNOWN_EXCEPTION</faultcode>
            <faultstring>UNKNOWN_EXCEPTION: Async job could not be executed</faultstring>
        </soapenv:Fault>
    </soapenv:Body>
</soapenv:Envelope>

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?