6

I am losing the field level security on fields which I deploy to production using Change Sets. This is a problem which has been discussed on here in the past :

Deploying From Sandbox (Enterprise) - loss of permissions, field security, etc

However, I have some further questions regarding this. If I am understand this all right then this is a serious drawback to deploying fields because it sounds like we are required to deploy all of the profiles from the said sandbox to production as well in order to maintain the proper field level security ... ???

If that is true then am I required to deploy ALL of the profiles in order to account for a field which is meant to be visible and editable by ALL profiles ? If that's true then that's crazy !

So far I have only deployed through Change Sets. Will Eclipse maintain the field level security if you use it to deploy new fields ? I've tested it on a couple of fields but only going from Prod -> Sandbox, not Sandbox->Production.

Thank you very much for your help and insight.

11

You have to include any profiles you want if they need access to any of the fields. Typically, the way this works is it uses the Ant Migration Tool. When you attempt to actually retrieve a profile from the specified org, it will only pull down permissions for the other items specified in the deploy. This means if you are only adding a single field, your profile being deployed will only have a single field in it as well. Since profiles will not overwrite each other, it simply applies the new person for that new field to the existing profile in the target org.

Long story short, the only permissions that get deployed for a specified profile are exactly related to the other items in your deploy. If you have a 1 field, 1 visualforce page, and 1 page layout, only the permissions related to those 3 objects will be pushed to the target org and the remainder of the permissions will be in tact. It will not overwrite other permissions.

  • Thanks for your input Jesse. So, if I want to move 5 new fields into Production which are set to be visible to everyone I have to go out there and choose to include EVERY profile in the deploy ?!?! That's crazy ! How am I supposed to convince the rest of my team to only develop in a sandbox (not directly in Prod) when they are doing day-to-day maintenance and additions ? That's the type of thing that makes them want to just go into Prod and do it. There's no way around that ? – Zoom_v Aug 8 '13 at 15:28
  • 2
    No, you have to specify the profiles. It really shouldn't be that bad to specify them. You can set up a base changeset that includes all profiles and then clone off of that changeset for every new one so that all of the profiles are already selected. – Jesse Altman Aug 8 '13 at 15:50
  • Thinking about this a little further - I guess the "easy" solution to this would be to just automatically include ALL Profiles from the sandbox in every deploy, even if only 20 of them would be able to see the field. That way you just need to click the Select All button on profiles and don't have to worry about going through the whole list and selecting the ones who will need the new field. (Assuming the sandbox would have all of the profiles needed).Does that sound like a good "work-around" for this ? – Zoom_v Aug 8 '13 at 16:06
  • ha - you must have written your comment just before I typed mine because that's what I was thinking :-) Thanks again Jesse ! – Zoom_v Aug 8 '13 at 16:08
  • I just realized you said a deployment will only carry over the profiles rights of the items in the deploy. I am now interested in deployments for profiles from Prod, not fields\pages etc. So, if I understand you correctly I will need to include EVERYTHING included in the Production profile in order for it to get transfered to the Sandbox. Is that true ? But I'm assuming the rights for those elements will remain the same if they are already specified in the Sandbox version of the profile ? Is that true ? I hope so. Thanks again Jesse. – Zoom_v Aug 12 '13 at 16:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.