Field Security profiles, unmanaged solutions, and why we should actually be looking at the warnings in the solution import logs

There is an interesting problem that we’ve just discovered. Something fishy has been going on with the field security profiles in our solutions – some time ago we’ve noticed that, every now and then, some of the field security profiles would not be properly updated in the destination environment after importing our updated solution there.

At first we thought maybe it was just a glitch, but, a few weeks later, it happened again. So it was a somehow persistent glitch which was becoming a bit of a problem.

A colleague of mine suggested that there might be something in the solution import logs. Those logs are always filled up with some warnings about workflows and sdk message processing steps, and it’s a big solution.. so more often than not we just don’t pay attention. It’s an unmanaged solution, btw.

Well, once the problem happened again.. Actually, one we’ve discovered the problem again (there is a difference), we’ve tried re-importing the same solution to the environment where the problem just happened. There was nothing about the security profiles in the logs. No luck? Was it really a glitch happening whenever it wanted to happen?

Luckily, we had a backup of the database taken before our updated solution was deployed, and, since we are on-prem, we tried restoring the database and importing the solution there.

There was our glitch, right in the logs:

Now this was all happening in 8.2 (and this is also important).

After a bit more testing, here is what we’ve discovered:

• You can add a new field to the solution, enable field security on that field, and add it to a field security profile. Then you can export that solution and import it to the destination. It will work.
• However, if you already have a field in both environments, but field security is not, yet, enabled in the target environment, importing the solution will lead to a warning above.

This is because a field can be added to field security profile only after that field has been enabled for field security, and, if it’s an existing field, that kind of change has to be published first. This is different from when a field is being created with field security enabled – that operation is automatically published.

And you know what else is interesting? This is not a problem.. well, sort of.. anymore in v9, since, if you run into this situation in V9, you’ll get an error (not a warning), so solution import will simply fail:

Which is probably a better option since, at least, you’ll know that it did not work – won’t have to wait till your users discover the problem.

Still, whether it’s V8 or V9, we may need some kind of a workaround, and, it seems, the easiest one would be to move Field Security Profiles into a separate solution, so the whole import process would look like this:

• Import the main solution (which would not include field security profiles)
• Publish all customizations (field security will be enabled on the secured fields after this)
• Import the second solution which would contain your field security profiles

PS. And what about the managed solutions? I suspect they should work just fine in the same scenario since changes imported through the managed solutions are published automatically. So a field would become enabled for field security profile, and, then, Dynamics would be able to configure the profile(s) without issues.