We are using the Metadata API to add Custom Fields to the Account object in Salesforce. We are able to create the custom fields, but then the Salesforce user has to manually login to their account and set the Field-Level Security to "Visible" for each Custom Field. Is there a way to set the visibility of the field or to set the permissions for the fields we add via the Metadata or Soap API's when we add the fields?
-
There is already a [post][1] in stack exchange.Please look at it. [1]: salesforce.stackexchange.com/questions/34521/…– sfdcCommented May 23, 2014 at 19:23
-
Thanks for the reply. We saw that post, but we were wondering if there was a direct method within the Metadata API. Maybe defining a PermissionSet (metadata.permissionset) using the API functions.– csMapsCommented May 23, 2014 at 19:53
Add a comment
|
3 Answers
If you have an existing PermissionSet you can use an associated FieldPermissions to grant Read permissions. This can be done via the Partner API.
Set the:
Fieldto 'Account.CustomField__c' (where CustomField__c is the API name of your field)ParentIdto the ID of the existing PermissionSet,SobjectTypeto 'Account'PermissionsReadto true
answered May 26, 2014 at 2:28
-
-
@sfdcfox Perhaps not. As you answered, profile based access may be preferable. PermissionSets would be more applicable if the field access didn't align with the current profiles. Commented May 26, 2014 at 8:26
You can use the Profile object in the metadata API to deploy object and field level permissions for the new object/fields. Read the documentation for more details.
-
Thanks for your replies - We've looked at both your comments and Daniels comments, plus the documentation (and many threads), but we still don't understand how to implement the permission change. There is something basic we're missing. We've added the Custom Fields using a create call [metaCustomFieldsResult = myMetaService.create(metaCustomFields)], and we've looked at declaring field level security [Dim fieldSecurity As New sfMetadata.ProfileFieldLevelSecurity], but we can't determine how to access the custom fields in the "Account" object and then to apply the new security values.– csMapsCommented May 29, 2014 at 17:23
-
-
We've made some additional discoveries (by doing a Select of the Field Permissions table in the Developer Console). All of the Custom Fields we created have PermissionsEdit and PermissionsRead set to true (so that's not the problem). If we log into Salesforce and check the System Administrator visibility property in the Field-Level Security, the custom field now works and is listed in our [myService.describeSObjects({"account"})] call. The missing visibilities seems to be our problem. Is there a setting in Salesforce that our customers need to enable/disable? Or can we adjust in the API?– csMapsCommented May 29, 2014 at 22:01
-
@csMaps I was going to update this answer when I got home, but basically you just need to deploy field level security with the fields. This is done with the profile metadata object. You can do this via API. Something like: query all standard profiles, generate object and profile payload, then deploy. You can deploy both new fields and profile permissions at once.– sfdcfox ♦Commented May 29, 2014 at 22:38
-
This is unbelievably hard for something that should be very easy!! We've started doing queries in the Developer console, looking at PermissionSets associated with 'Standard' Profiles, and looking at FieldPermissions. All of the fields appear to be set correctly, so we have no idea which field we want to change that is equivalent to setting the Field-Level Security to visible in the UI. Plus we have no idea how to deploy in the Metadata API without having to generate external packaged Zip files.– csMapsCommented May 30, 2014 at 15:31
We answered the question (with suggestions from sfdcfox in this thread and blogs by Terry Luschen). We provided a detailed description of our answer at the Salesforce Developer Forum.
We still have some outstanding issues regarding support for Dynamic Custom Fields for users with Salesforce Profession Edition and on record limits when using the SOAP API to transfer data. Any guidance on those topics is welcome.
-
Without salesforce actively enabling the org for API access, you cannot access those orgs via metadata API. Only the SOAP and REST API (CRUD operations) are supported for partners at this time. The usual policy is never to enable the API for GE, and only for a limited time on PE. See also the ISVForce guide for details on accessing orgs using client id (SOAP) or a connected app with bonus permissions (REST).– sfdcfox ♦Commented Jun 13, 2014 at 17:01
-
I'm not sure I understand your comment (or the documentation). Does using a Connected App allow for Custom Fields to be added to the standard Account or Contact objects if your PE user?– csMapsCommented Jun 16, 2014 at 13:47
-
My apologies for any confusion. No, there is no way to access the metadata API in PE or GE without having the API turned on for that org. This comes by either buying it a la carte, or asking nicely, in which case it may be temporarily enabled.– sfdcfox ♦Commented Jun 16, 2014 at 15:09
-
That coincides with what I'm reading. Thanks for the feedback.– csMapsCommented Jun 16, 2014 at 18:53
-
I recently got asked about this, the MD update API does work when adding FLS to a profile, however it only works if you send just what you want. Here is an example using the Apex Metadata API wrapper, but the principle is the same in other languages, github.com/financialforcedev/apex-mdapi/issues/… Commented Jan 16, 2015 at 9:27