4

My experience has shown two distinct behaviors.

Case 1: Placeholder Profile "Profile 27" created in production. Production org copied to Sandbox. Development and config occurs in sandbox. Change set is used to promote code, config, Profile 27, as well as field-level and object-level security. This works.

Case 2: Production org copied to Sandbox. Development and config occurs in sandbox. Profile 28 is created in sandbox. Change set is used to promote code, config, Profile 28, as well as field-level and object-level security.
After deployment Profile 28 exists in Production, but the FLS is foobar and must be configured by hand.

It appears that in order for object and field level security details to promote correctly with a profile, the following must be true: 1) profile is included in change set 2) objects/fields to which profile has access are included in change set 3) profile must already exist in target org, and must have been populated to source org by copy/refresh

Is there any way of creating a new profile in a sandbox, and promoting it to the production org in such a way that Field level and Object level security is correctly promoted as well?

Improve this question

3 Answers 3

Reset to default
4

I have consistently had problems with deploying profiles. It is incredibly difficult to get them to work with anything even remotely large. Specifically, there have been times where multiple projects have been worked on at a single time within a single organization. So, two sandboxes, one project going on in each of them, and then deploying that change causes issues. This is normally due to the fact the profile metadata doesn't match what it should because the organizations have access to different objects that aren't available in each environment due to the nature of the development.

Normally, I account for a significant amount of manual work in any of our deployments related to profiles. That seems to be the best approach so far as everything else has been unreliable.

Improve this answer
1
  • +1, I do this as well - deploying profiles is unreliable and frankly dangerous since many times developers will unwittingly make a security change in a sandbox that you don't want deployed. Sometimes you can save time by deploying permission sets for big changes and then manually granting that permission set to the appropriate profiles after deployment.
    – jkraybill
    Feb 7, 2013 at 7:19
0

Profiles are not one of the metadata components that can be deployed via changesets. I'm frankly surprised that it is even creating the profile in case 2. I would try the following and see if it works:

  • Re-deploy the changeset after the profile exists in production
  • Manually create a profile with the same name and see if FLS is applied.
Improve this answer
2
  • There is a section on the Change Set interface titled "Profile Settings For Included Components" which lets you choose profiles to be included.
    – Mark Pond
    Feb 7, 2013 at 6:26
  • @MarkPond I was aware of that but I believe it is only for profile settings relating to objects, fields, tabs, etc. similar to how the force.com ide works when you pull down profiles and objects. I don't believe it sets any of the profile-specific fields (checkboxes).
    – Greg Grinberg
    Feb 7, 2013 at 20:54
0

Yes. The best way to deploy a profile that includes all the permissions, including Field Level Security, pages, etc. is using the "Full Profiles" deployment functionality of Copado Deployer appexchange app https://appexchange.salesforce.com/listingDetail?listingId=a0N3000000B3dgGEAR

and the 2 orgs does not need to be exactly the same, the tool will clean the differences for you.

kind regards.-

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .