CRM 2011 Field level security for OOB attributes

Lately I’ve been hearing this word “It can’t be done” or “It’s not possible” all the time and it’s getting annoying, these words/phrases are poison to developers, especially young people who are just starting out their career, when all they hear is “can’t / not possible” it conditions them to think that way by default, it gets even worse when you get them in-front of customers and instead of thinking and coming up with a solution the default answer becomes “can’t” or “not possible”.

Let’s take a real word example using CRM 2011.

Today we were talking about field level security and couple of people said “It can’t be done for out of the box fields in CRM 2011”, “it’s not possible for out of the box fields”…this is simply not true, the Dynamics CRM team are a smart bunch of people that won’t hard code limitations like that, so to clear this up let’s open up SQL Management Studio and take a peek at the metadata.

Open up the MetadataSchema.Attribute table from *_MSCRM org database, filter on any attribute (eg: accountnumber)

By default the CanBeSecured* columns will be set to False, all you have to do is make these fields True, then you have the ability to enable/disable Field Security on the attribute.

So far so good, making progress…odds not looking good for the nay sayers…

The only other thing that’s left to do is to insert 2 rows into the FieldPermissionBase table, first row with ComponentState=2 and second row with ComponentState=0

FieldPermissionIdUnique has to be a unique guid for both rows
ComponentState 0 or 2
SolutionId find the default solution or your solution id and use that guid
Can* 4
SupportingSolutionId empty guid
FieldSecurityProfileId grab one from the FieldSecurityProfileBase
EntityName mislabelled db column, it’s actually wanting the typecode of the entity, not the logical name
OverwriteTime set to 1900-01-01
AttributeLogicalName logical name of the attribute

And the result

There we have it! Field Level Security on out of the box attributes. Next time consider saying “I don’t know” instead of “can’t”.

15 Comments

  • I didn't think it was possible, and although your methdod might be a little unsupported it is, as my Kiwi friends would say, "Suuuuweeeet AS, bru!"

  • Hehehe here in NZ some of my friends started using "brew" instead, from that blood diamond movie...

  • I can do lots of 'impossible' things in CRM by using unsupported techniques, but that does not make them acceptable to 'most' of my clients (although sometimes they ARE accepted as the cost of making a system work as it needs to). We have to be willing to step out of bounds when necessary, but I think it's a little unfair to bash on people who say 'can't' because they are sticking with 'supported' customizations. If you are saying 'can't' just as a shortcut I agree that is bad, but seeing this solution I would still tell most clients that they 'can't' secure OOB fields without sacrificing supportability of the system and adding risk, particularly if any of this reverse-engineered behavior changes in a future patch/update - but also because I don't feel confident we can always anticipate every possible interaction in the system with many OOB fields that could cause downstream problems later with OOB functionality (such as converting leads to opportunities, etc). I assume that as you say, the developers are smart, and have probably disabled those flags for a reason.

    This is cool though, don't get me wrong. We have done custom field-level security (plugins, etc) in the past and I would not be opposed to using this approach if it passed client muster and they were ok with its 'unsupported' nature.

  • Hi Ken

    I agree with you 100%, and like you say people use the words "can't" and "not possible" too loosely without explaining the reasoning behind it.

    I myself wouldn't recommend or implement this solution on a live server, this was to prove that it is possible and saying "can't" without any legs behind the reasoning is an easy way out, do this enough times and you become conditioned in that way of thinking...

    I expected this blog post to ruffle a few feathers, just wanted to make everyone aware of the differences between "can't", "I don't know" and "unsupported", completely different things/meanings.

  • Great info, wondering if this work around is possible with the CRM Online. Thanks

  • Hi Derek

    If we had direct access to the crm 2011 online database we could, but it's protected :)

  • Why do you need two separate entries for componentstate? What does componentstate represent?

  • I'm not sure, I didn't digg into that, when I turned on field level security for a custom entity that's what came up on that table. You could try leaving 1 entry and see if it works.

  • Gayan,

    Have you tried looking at the Solution / Customizations XML and seeing if there are Tags that can be set in there in order to set the Field Security for default attributes?

    Just a thought, that when the Solution XML is imported & published that might create the associated database entries?

    There were similar Customizations-based XML workarounds in CRM 4.0, I recall...

  • Ahh very good point, I'll check that and let you know, that'd make it much easier than hacking the database

  • This is of course not supported and one big issue: creates duplicate row in MetadataSchema.Attribute table. I tried to secure system field 'parentaccountid' and two rows in this table appeared with the same attributeid - I think when you export and import solution with this object included you will get nice error because duplicate in database exists :)

  • Do you think this will continue to work when you install update rollups ?

  • I like Ken's comment, and the last few comments. Kind of brings it full circle. I've had the privilege of working for a few large customers lately who had gotten into the habit of using unsupported customizations/data imports. They are now paying, and total cost of ownership which was once thought to be lower now, of course, turned out to be higher.

    To the casual reader - it's not supported for some good reasons, so caveat emptor. Who knows, maybe you'll be gone by the time someone figures out it caused so many issues and ther'll be noone standing to blame.

  • Do yourself a favor and DON'T do what this article says. Its unsupported. Try exporting and importing into an environment that has these hacks in place, OR try upgrading.. It will fail.
    Create a custom field for what you need, then set field security on that field. Problem solved.

  • Hi,
    How this can be achieved for Dynamics CRM Online? Thanks in advance.

Comments have been disabled for this content.