+ Start a Discussion
JanMJanM 

Custom Field Permissions from Metadata API

We've successfully added a number of Custom Fields using the Metadata API.  Our site is an Asp.net and we're using VB for coding (thought about posting to .NET Development, but our question is more API focused).  First we build a Custom Field: 
metaCustomField = New sfMetadata.CustomField
metaCustomField.fullName = "Account.TestField__c"
metaCustomField.description = "Test Field for Account"
metaCustomField.inlineHelpText = "Test Field for Account"
metaCustomField.label = "Field Label"
metaCustomField.length = 20
metaCustomField.lengthSpecified = True
metaCustomField.unique = False
Then we add the Custom Field to an Array of Custom Fields (metaCustomFields).  There are roughly 40 fields, so we limit the array to 10 and submit each batch of 10 fields using:
metaCustomFieldsResult = myMetaService.create(metaCustomFields)
This all works well, and the fields are created as desired.  The first time we created the fields, it worked perfectly and we were then able to use the Soap API to populate the Account object with data (including the custom fields).

However, for some reason, if we delete a Custom Field and then add it again, or if we test using other Salesforce logins, the fields are getting generated properly, but the permissions on the fields are no longer being set (none of the "Field-Level Security" is set to visible).  We're not sure what we changed, but we've begun looking into how to apply Permission Sets to the Custom Fields for the Account object.  There appears to be a couple concepts to consider.  First, we've seen some code for building a package.xml file listing our field permissions and then submitting the zipfile:
<fieldPermissions>
     <editable>true</editable>
     <readable>true</readable>
     <field>Account.TestField__c</field>
</fieldPermissions>
In addition, we noticed that there are some additional Metadata API functions that look like they might help, but we can't find any details or code samples on how to apply them:
' Will adding either of these lines to the
' Custom field definition help:
metaCustomField.visibleLines = 1
metaCustomField.writeRequiresMasterRead = True

' Or, define a Permission Set
metaFieldPermission = New sfMetadata.PermissionSet
' Not sure what to do with it from here...

Can anyone tell us if we are heading in the right direction, or if there is a preferred method for setting the "Visible" Field-Level Security permissions for the custom fields we have created?

Best Answer chosen by JanM
JanMJanM
 OK, we resolved our issue about a week ago, but we’ve been too busy implementing the results for me to follow-up with the answer.  Since there seems to be a frustrating amount of unanswered Salesforce threads, I wanted to take a moment to follow-up on this thread.

First, we have been running a parallel thread at:
http://salesforce.stackexchange.com/questions/36846/metadata-api-custom-field-permissions
 

We wouldn’t have solved our problem without the assistance of sfdcfox on the other thread, and the blogs offered by Terry Luschen (So, Thank you to both of you!).  Here are the Blogs from Terry that we found helpful (they are in vb.net, but could easily be converted to C#):

Retrieve:  http://www.sundoginteractive.com/sunblog/posts/calling-retrieve-from-the-metadata-api-in-vb.net
Deploy: http://www.sundoginteractive.com/sunblog/posts/calling-the-salesforce-metadata-api-from-vb.net

Basically, we moved away from building the custom fields and permissions in pure code and switched to using xml deploys.  The code version required us to batch up our custom fields in groups of 10 and then to submit those with a “create” statement (see our earlier note).  This worked, but then we couldn’t figure out how to submit the proper permissions (now that we have the xml profiles working, maybe we could try to emulate the profile file in code, but the xml version is the better solution for us).  The xml deploy approach allowed us to batch all of our custom fields requirements together (we were adding 40+ fields to Accounts and 10+ fields to Contacts), along with the profiles and submit them with a single deploy.

Next it took us a while to figure out the structure of the deployment package.  The Metadata documentation has a lot of great information, but it is also lacking in how to bundle everything together for a finished solution.  It wasn’t until we read the blog from Terry Luschen for performing a deploy from code, and we combined that information with running his code for retrieving the zip package that we figured this out.  By retrieving a package, we were able to see the directory structure and file names that the zip file required.  (Note:  We didn’t download the .Net zip packages that Terry suggests, since we weren’t dynamically building the zip package.  We zipped and unzipped locally on our development machine, but I strongly recommend performing a retrieve to see the proper structure.)

Here are the actual steps we took to build our deploy file:

1.)  We created a Directory we titled “DeployFiles”
2.)  Within the DeployFiles directory we created a directory titled “objects”
3.)  In the objects directory we created our custom field files.  The key was to name the files appropriately:

The account fields were in a file named “Account.object” and the structure looked like this:

<?xml version="1.0" encoding="utf-8"?>
<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata">
 <deploymentStatus>Deployed</deploymentStatus>
 <description>Setup Custom Fields for Account Standard Object</description>
 <fields>
  <fullName>AccountTestField1__c</fullName>
  <description>Account Test Field 1</description>
  <inlineHelpText>Account Test Field 1</inlineHelpText>
  <label>Account Field 1</label>
  <type>Text</type>
  <length>10</length>
 </fields>
 <fields>
  <fullName>AccountTestField2__c</fullName>
  <description>Account Test Field 2</description>
  <inlineHelpText>Account Test Field 2</inlineHelpText>
  <label>Account Field 2</label>
  <type>Text</type>
  <length>20</length>
 </fields> 
</CustomObject>
The contact fields were in a file named “Contact.object” and the structure looked like this:
<?xml version="1.0" encoding="utf-8"?>
<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata">
 <deploymentStatus>Deployed</deploymentStatus>
 <description>Setup Custom Fields for Contact Standard Object</description>
 <fields>
  <fullName>ContactTestField1__c</fullName>
  <description>Contact Test Field 1</description>
  <inlineHelpText>Contact Test Field 1</inlineHelpText>
  <label>Contact Field 1</label>
  <type>Text</type>
  <length>10</length>
 </fields>
 <fields>
  <fullName>ContactTestField2__c</fullName>
  <description>Contact Test Field 2</description>
  <inlineHelpText>Contact Test Field 2</inlineHelpText>
  <label>Contact Field 2</label>
  <type>Text</type>
  <length>20</length>
 </fields> 
</CustomObject>

4.)  Next we created a directory in the DeployFiles directory titled “profiles”
5.)  In the profiles directory we created two files (we’re not sure if we only needed one of these, or if there should be more profile files, but it seems to be doing the job for us so far).  Both files had the exact same content, but the different file names are important:


The admin (System Admin) permissions were placed in a file named “Admin.profile” and the Standard User permissions were placed in a file named "Standard.profile".  Both files had the same content:


<?xml version="1.0" encoding="utf-8"?>
<Profile xmlns="http://soap.sforce.com/2006/04/metadata">
 <userPermissions>
  <enabled>true</enabled>
  <name>ApiEnabled</name>
 </userPermissions>
 <fieldPermissions>
  <field>Account.AccountTestField1__c</field>
  <editable>true</editable>
  <hidden>false</hidden>
  <readable>true</readable>
 </fieldPermissions>
 <fieldPermissions>
  <field>Account.AccountTestField2__c</field>
  <editable>true</editable>
  <hidden>false</hidden>
  <readable>true</readable>
 </fieldPermissions> 
 <fieldPermissions>
  <field>Contact.ContactTestField1__c</field>
  <editable>true</editable>
  <hidden>false</hidden>
  <readable>true</readable>
 </fieldPermissions>
 <fieldPermissions>
  <field>Contact.ContactTestField2__c</field>
  <editable>true</editable>
  <hidden>false</hidden>
  <readable>true</readable>
 </fieldPermissions>
</Profile>
6.)  Finally, we created the "package.xml" file and placed it in the DeployFiles directory.  It looked like this:
<?xml version="1.0" encoding="utf-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
 <types>
  <members>Account.AccountTestField1__c</members>
  <members>Account.AccountTestField2__c</members>
  <members>Contact.ContactTestField1__c</members>
  <members>Contact.ContactTestField2__c</members> 
  <name>CustomField</name>
 </types>
 <types>
  <members>Admin</members>
  <members>Standard</members>
  <name>Profile</name>
 </types>
 <version>29.0</version>
</Package>

7.)  Now the DeployFiles Directory structure looked like this:

          DeployFiles
              package.xml
              objects
                  Account.object
                  Contact.object
               profiles
                   Admin.profile
                   Standard.profile

8.) Then we zipped the DeployFiles directory in to a .zip file and added it to our project (in Visual Studio we placed it in App_Data).
9.)  Here's a subset of the code we used to deploy the file (See links from Terry above for more details and "waitUntilDone" routine):
' Initalize MetaService
' Login to MetaData Service (For Managing Fields)
myMetaService = New sfMetadata.MetadataService
myMetaService.Url = myLoginResult.metadataServerUrl
myMetaService.SessionHeaderValue = New sfMetadata.SessionHeader
myMetaService.SessionHeaderValue.sessionId = myLoginResult.sessionId.ToString

' Set up Deploy Options
deployOpts.runAllTests = False
deployOpts.runTests = Nothing
deployOpts.autoUpdatePackage = False
deployOpts.allowMissingFiles = False
deployOpts.checkOnly = False
deployOpts.ignoreWarnings = False
deployOpts.performRetrieve = False
deployOpts.purgeOnDelete = False
deployOpts.rollbackOnError = True
deployOpts.singlePackage = False

' Get the Packaged Zip File Path
strAppDataPath = GetAppDataPath()
strZipFullPath = strAppDataPath & "DeployFiles.zip"

' Verify Zip file exists
If System.IO.File.Exists(strZipFullPath) Then

' Load the Zip File
byteFile = LoadFile(strZipFullPath)
' Deploy the Package
asyncResultItem = myMetaService.deploy(byteFile, deployOpts)

' Wait Until Done
If asyncResultItem.done = False Then
 waitUntilDone(asyncResultItem.id)
End If

' Get Deploy Result
newDeployResult = myMetaService.checkDeployStatus(asyncResultItem.id, True)
If newDeployResult.success Then
 strResult = "Complete"
Else
 { Handle Errors }
End If
10.)  It took us a while to debug our routines and set the appropriate Deploy Options.  Originally we weren't receiving any errors other than "Payload Error", but once we got the structure close to what we needed, the error messages started becoming more useful.  There is no guarentee that we have all of these files right, and you'll need to adjust them for your needs, but hopefully the documentation can be of assistance.  One note we learned from sfdcfox was that you can all check for Deploy Errors by logging into Salesforce and going to Setup > Deploy > Deploy Status.

This solution is working for us so far and hopefully this information will be helpful to you.  We still have some outstanding issues we need to address:

    - It appears that Salesforce limits the Professional Edition functionality (unless you call and can talk the rep into enabling API's?), so our clients will need Enterprise Edition or above.  We're trying to learn more about this now.
   -  Also, we're using the SOAP API for populating the Custom Fields we've created with data.  So now we're concerned about Salesforce quantity limits and not sure if that will become an issue for us down the road.

Any tidbits or suggestions associated with those two issues is greatly appreciated.

All Answers

JanMJanM
 This is a second version of an earlier note (which we deleted).  This edition has updated xml files and an updated status of our progress:

We've been receiving a lot of help on our question listed on Salesforce StackExchange (See http://salesforce.stackexchange.com/questions/36846/metadata-api-custom-field-permissions),  As a result, we're now attempting to solve this issue using a ZIP file ("Package") method.  However, we are now struggling with getting the new method to work and can't see to locate a good example.  Here's what we have so far...

First we created a CustomObject.xml file (updated xmlns and "fields" elements):

<?xml version="1.0" encoding="utf-8"?>
<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata">
 <deploymentStatus>Deployed</deploymentStatus>
 <description>Setup Custom Fields for Account and Contact Standard Objects</description>
 <fields>
  <fullName>Account.AccountField1__c</fullName>
  <description>Account Custom Field 1</description>
  <inlineHelpText>Account Custom Field 1</inlineHelpText>
  <label>AccountField1</label>
  <type>Text</type>
  <length>10</length>
 </fields>
 <fields>
  <fullName>Account.AccountField2__c</fullName>
  <description>Account Custom Field 2</description>
  <inlineHelpText>Account Custom Field 2</inlineHelpText>
  <label>AccountField2</label>
  <type>Text</type>
  <length>20</length>
 </fields>
 <fields>
  <fullName>Contact.ContactField1__c</fullName>
  <description>Contact Custom Field 1</description>
  <inlineHelpText>Contact Custom Field 1</inlineHelpText>
  <label>ContactField1</label>
  <type>Text</type>
  <length>10</length>
 </fields>
 <fields>
  <fullName>Contact.ContactField2__c</fullName>
  <description>Contact Custom Field 2</description>
  <inlineHelpText>Contact Custom Field 2</inlineHelpText>
  <label>ContactField2</label>
  <type>Text</type>
  <length>20</length>
 </fields>
</CustomObject>

Then we created a Profile.xml file (removed Deploy Status and Description):

<?xml version="1.0" encoding="utf-8"?>
<Profile xmlns="http://soap.sforce.com/2006/04/metadata">
 <userPermissions>
  <enabled>true</enabled>
  <name>APIEnabled</name>
 </userPermissions>
 <fieldPermissions>
  <field>Account.AccountField1__c</field>
  <editable>true</editable>
  <hidden>false</hidden>
  <readable>true</readable>
 </fieldPermissions>
 <fieldPermissions>
  <field>Account.AccountField2__c</field>
  <editable>true</editable>
  <hidden>false</hidden>
  <readable>true</readable>
 </fieldPermissions>
 <fieldPermissions>
  <field>Contact.ContactField1__c</field>
  <editable>true</editable>
  <hidden>false</hidden>
  <readable>true</readable>
 </fieldPermissions>
 <fieldPermissions>
  <field>Contact.ContactField2__c/field>
  <editable>true</editable>
  <hidden>false</hidden>
  <readable>true</readable>
 </fieldPermissions>
</Profile>

And finally, we created a Package.xml file (added specific members for the custom fields and changed version):

<?xml version="1.0" encoding="utf-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
 <types>
  <members>Account.AccountField1__c</members>
  <members>Account.AccountField2__c</members>
  <members>Contact.ContactField1__c</members>
  <members>Contact.ContactField2__c</members>
  <name>CustomField</name>
 </types>
 <types>
  <members>*</members>
  <name>Profile</name>
 </types>
 <version>29.0</version>
</Package>

Then we zipped all three files in to DeployFiles.zip and used the following code to load the package (we've tried different Deploy options):

' Set up Deploy Options
deployOpts.runAllTests = False
deployOpts.runTests = Nothing
deployOpts.autoUpdatePackage = False
deployOpts.allowMissingFiles = False
deployOpts.checkOnly = False
deployOpts.ignoreWarnings = False
deployOpts.performRetrieve = False
deployOpts.purgeOnDelete = False
deployOpts.rollbackOnError = False
deployOpts.singlePackage = True

' Verify Zip file exists
If System.IO.File.Exists(strZipFullPath) Then

     ' Load the Zip File
     byteFile = LoadFile(strZipFullPath)
    ' Deploy the Package
   asyncResultItem = myMetaService.deploy(byteFile, deployOpts)

    ' Wait Until Done (Not being used)
    'If asyncResultItem.done = False Then
    '    waitUntilDone(asyncResultItem.id)
    'End If

     ' Get Deploy Result
     newDeployResult = myMetaService.checkDeployStatus(asyncResultItem.id, True)
     If newDeployResult.success Then
          ' Indicate Success
          strResult = "Complete"
     End If

End If

We like the concept of this approach and DeployFiles.zip file is read and submitted by the deploy.  However, we are not receiving a success indication and the custom fields are not being added.  When we check the "Deploy Status" in our Salesforce Developer Edition, it is showing a Payload Error, with a detail message of "No package.xml found".  We've tried changing the case of the Package file name (now called "package.xml"), but that didn't help.  We're now wondering if our zip file is not getting unzipped properly, or if we should only have one file in each deploy.

We have found many snippits of how to get our simple task completed, but we can't seem to find an all in compassing example.  Any help is appreciated.


rajesh k 10rajesh k 10
Hi,
             I also same problem,like Actually i created fields using metadata api but created fileds Field-Level Security for Profile(Administrator) place visible and editable checkboxes not checked(any profile not checked i am a administrator).Every time i will goto Setup->Manage->users>administrator->custom field level security->related object name and click view and checked to metadata created fields visible and editable.How to check this visible and editable checkboxes Using apex DML permissionsets dynamically through Coding?.

please help me............
JanMJanM
 OK, we resolved our issue about a week ago, but we’ve been too busy implementing the results for me to follow-up with the answer.  Since there seems to be a frustrating amount of unanswered Salesforce threads, I wanted to take a moment to follow-up on this thread.

First, we have been running a parallel thread at:
http://salesforce.stackexchange.com/questions/36846/metadata-api-custom-field-permissions
 

We wouldn’t have solved our problem without the assistance of sfdcfox on the other thread, and the blogs offered by Terry Luschen (So, Thank you to both of you!).  Here are the Blogs from Terry that we found helpful (they are in vb.net, but could easily be converted to C#):

Retrieve:  http://www.sundoginteractive.com/sunblog/posts/calling-retrieve-from-the-metadata-api-in-vb.net
Deploy: http://www.sundoginteractive.com/sunblog/posts/calling-the-salesforce-metadata-api-from-vb.net

Basically, we moved away from building the custom fields and permissions in pure code and switched to using xml deploys.  The code version required us to batch up our custom fields in groups of 10 and then to submit those with a “create” statement (see our earlier note).  This worked, but then we couldn’t figure out how to submit the proper permissions (now that we have the xml profiles working, maybe we could try to emulate the profile file in code, but the xml version is the better solution for us).  The xml deploy approach allowed us to batch all of our custom fields requirements together (we were adding 40+ fields to Accounts and 10+ fields to Contacts), along with the profiles and submit them with a single deploy.

Next it took us a while to figure out the structure of the deployment package.  The Metadata documentation has a lot of great information, but it is also lacking in how to bundle everything together for a finished solution.  It wasn’t until we read the blog from Terry Luschen for performing a deploy from code, and we combined that information with running his code for retrieving the zip package that we figured this out.  By retrieving a package, we were able to see the directory structure and file names that the zip file required.  (Note:  We didn’t download the .Net zip packages that Terry suggests, since we weren’t dynamically building the zip package.  We zipped and unzipped locally on our development machine, but I strongly recommend performing a retrieve to see the proper structure.)

Here are the actual steps we took to build our deploy file:

1.)  We created a Directory we titled “DeployFiles”
2.)  Within the DeployFiles directory we created a directory titled “objects”
3.)  In the objects directory we created our custom field files.  The key was to name the files appropriately:

The account fields were in a file named “Account.object” and the structure looked like this:

<?xml version="1.0" encoding="utf-8"?>
<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata">
 <deploymentStatus>Deployed</deploymentStatus>
 <description>Setup Custom Fields for Account Standard Object</description>
 <fields>
  <fullName>AccountTestField1__c</fullName>
  <description>Account Test Field 1</description>
  <inlineHelpText>Account Test Field 1</inlineHelpText>
  <label>Account Field 1</label>
  <type>Text</type>
  <length>10</length>
 </fields>
 <fields>
  <fullName>AccountTestField2__c</fullName>
  <description>Account Test Field 2</description>
  <inlineHelpText>Account Test Field 2</inlineHelpText>
  <label>Account Field 2</label>
  <type>Text</type>
  <length>20</length>
 </fields> 
</CustomObject>
The contact fields were in a file named “Contact.object” and the structure looked like this:
<?xml version="1.0" encoding="utf-8"?>
<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata">
 <deploymentStatus>Deployed</deploymentStatus>
 <description>Setup Custom Fields for Contact Standard Object</description>
 <fields>
  <fullName>ContactTestField1__c</fullName>
  <description>Contact Test Field 1</description>
  <inlineHelpText>Contact Test Field 1</inlineHelpText>
  <label>Contact Field 1</label>
  <type>Text</type>
  <length>10</length>
 </fields>
 <fields>
  <fullName>ContactTestField2__c</fullName>
  <description>Contact Test Field 2</description>
  <inlineHelpText>Contact Test Field 2</inlineHelpText>
  <label>Contact Field 2</label>
  <type>Text</type>
  <length>20</length>
 </fields> 
</CustomObject>

4.)  Next we created a directory in the DeployFiles directory titled “profiles”
5.)  In the profiles directory we created two files (we’re not sure if we only needed one of these, or if there should be more profile files, but it seems to be doing the job for us so far).  Both files had the exact same content, but the different file names are important:


The admin (System Admin) permissions were placed in a file named “Admin.profile” and the Standard User permissions were placed in a file named "Standard.profile".  Both files had the same content:


<?xml version="1.0" encoding="utf-8"?>
<Profile xmlns="http://soap.sforce.com/2006/04/metadata">
 <userPermissions>
  <enabled>true</enabled>
  <name>ApiEnabled</name>
 </userPermissions>
 <fieldPermissions>
  <field>Account.AccountTestField1__c</field>
  <editable>true</editable>
  <hidden>false</hidden>
  <readable>true</readable>
 </fieldPermissions>
 <fieldPermissions>
  <field>Account.AccountTestField2__c</field>
  <editable>true</editable>
  <hidden>false</hidden>
  <readable>true</readable>
 </fieldPermissions> 
 <fieldPermissions>
  <field>Contact.ContactTestField1__c</field>
  <editable>true</editable>
  <hidden>false</hidden>
  <readable>true</readable>
 </fieldPermissions>
 <fieldPermissions>
  <field>Contact.ContactTestField2__c</field>
  <editable>true</editable>
  <hidden>false</hidden>
  <readable>true</readable>
 </fieldPermissions>
</Profile>
6.)  Finally, we created the "package.xml" file and placed it in the DeployFiles directory.  It looked like this:
<?xml version="1.0" encoding="utf-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
 <types>
  <members>Account.AccountTestField1__c</members>
  <members>Account.AccountTestField2__c</members>
  <members>Contact.ContactTestField1__c</members>
  <members>Contact.ContactTestField2__c</members> 
  <name>CustomField</name>
 </types>
 <types>
  <members>Admin</members>
  <members>Standard</members>
  <name>Profile</name>
 </types>
 <version>29.0</version>
</Package>

7.)  Now the DeployFiles Directory structure looked like this:

          DeployFiles
              package.xml
              objects
                  Account.object
                  Contact.object
               profiles
                   Admin.profile
                   Standard.profile

8.) Then we zipped the DeployFiles directory in to a .zip file and added it to our project (in Visual Studio we placed it in App_Data).
9.)  Here's a subset of the code we used to deploy the file (See links from Terry above for more details and "waitUntilDone" routine):
' Initalize MetaService
' Login to MetaData Service (For Managing Fields)
myMetaService = New sfMetadata.MetadataService
myMetaService.Url = myLoginResult.metadataServerUrl
myMetaService.SessionHeaderValue = New sfMetadata.SessionHeader
myMetaService.SessionHeaderValue.sessionId = myLoginResult.sessionId.ToString

' Set up Deploy Options
deployOpts.runAllTests = False
deployOpts.runTests = Nothing
deployOpts.autoUpdatePackage = False
deployOpts.allowMissingFiles = False
deployOpts.checkOnly = False
deployOpts.ignoreWarnings = False
deployOpts.performRetrieve = False
deployOpts.purgeOnDelete = False
deployOpts.rollbackOnError = True
deployOpts.singlePackage = False

' Get the Packaged Zip File Path
strAppDataPath = GetAppDataPath()
strZipFullPath = strAppDataPath & "DeployFiles.zip"

' Verify Zip file exists
If System.IO.File.Exists(strZipFullPath) Then

' Load the Zip File
byteFile = LoadFile(strZipFullPath)
' Deploy the Package
asyncResultItem = myMetaService.deploy(byteFile, deployOpts)

' Wait Until Done
If asyncResultItem.done = False Then
 waitUntilDone(asyncResultItem.id)
End If

' Get Deploy Result
newDeployResult = myMetaService.checkDeployStatus(asyncResultItem.id, True)
If newDeployResult.success Then
 strResult = "Complete"
Else
 { Handle Errors }
End If
10.)  It took us a while to debug our routines and set the appropriate Deploy Options.  Originally we weren't receiving any errors other than "Payload Error", but once we got the structure close to what we needed, the error messages started becoming more useful.  There is no guarentee that we have all of these files right, and you'll need to adjust them for your needs, but hopefully the documentation can be of assistance.  One note we learned from sfdcfox was that you can all check for Deploy Errors by logging into Salesforce and going to Setup > Deploy > Deploy Status.

This solution is working for us so far and hopefully this information will be helpful to you.  We still have some outstanding issues we need to address:

    - It appears that Salesforce limits the Professional Edition functionality (unless you call and can talk the rep into enabling API's?), so our clients will need Enterprise Edition or above.  We're trying to learn more about this now.
   -  Also, we're using the SOAP API for populating the Custom Fields we've created with data.  So now we're concerned about Salesforce quantity limits and not sure if that will become an issue for us down the road.

Any tidbits or suggestions associated with those two issues is greatly appreciated.

This was selected as the best answer
rajesh k 10rajesh k 10
Hi JanM,
                  My requirement is when i create a field using metadata api in an visualforce page on that time only that field related visible check box will be check all profiles how(using apex coding related to metadata api)?

please help me........
Kashyap Patel 3Kashyap Patel 3
I just finished resolving this issue. Basically, if you set the API Version of your (RetrieveRequest.apiVersion) to something less than 30.0, then any new custom field you create will have a fieldPermission.editable default of true. If the API version is greater than or equal to 30.0, the default value of editable is false so you will have to also download the profiles and set the fieldPermission.editable to true.

Take a look at ProfileFieldLevelSecurity section at this link (https://www.salesforce.com/us/developer/docs/api_meta/index_Left.htm#CSHID=meta_profile.htm|StartTopic=Content%2Fmeta_profile.htm|SkinName=webhelp):
"In API version 30.0 and later, when deploying a new custom field, this field is false by default."
Andy FawcettAndy Fawcett
I recently got asked about this as question on the Apex Metadata API wrapper here (https://github.com/financialforcedev/apex-mdapi/issues/68). The poster actually led me here as they where having a challange updating the Admin profiles FLS via the Metadata updateMetadata'operation. I did some digging for them and thought i'd share my results. The following code is Apex code but the principle applies generally. 
 
MetadataService.MetadataPort service = createService();
MetadataService.Profile admin = new MetadataService.Profile();
admin.fullName = 'Admin';
admin.custom = false;
MetadataService.ProfileFieldLevelSecurity fieldSec = new MetadataService.ProfileFieldLevelSecurity();
fieldSec.field='Test__c.TestField__c';
fieldSec.editable=true;
admin.fieldPermissions  = new MetadataService.ProfileFieldLevelSecurity[] {fieldSec} ;
List<MetadataService.SaveResult> results = 		
	service.updateMetadata(
		new MetadataService.Metadata[] { admin });
Basically the Profile Metadata object allows you to partially populate it, meaning you can load it with only what you want to add or change and it will apply only those changes. Hope this helps folks!
Arun Garg 9Arun Garg 9
Best Answer Custom Permission Set Using Custom Metadata API , follow below link
Create Custom Permission Set Using Custom Metadata API Via JavaScript (http://www.salesforceadda.com/2017/08/create-custom-permission-set-using.html)
Shanmu P 6Shanmu P 6
Hi Andy Fawcett,
You have saved my day! It worked.Thanks...