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?
Best Answer
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.