CRM 2011 – Privileges by entity and privileges not associated with entities

I saw a tweet about the CRM release 5.04 which you can get here if you are interested.

Microsoft keep adding more and more sample code making it easier for people to develop with CRM, the new samples added in this release are

The sending of an email is quite interesting because I have seen code written which has used .NET code to send emails.  I hadn’t thought about using CRM to send the email, I don’t think anyone writing the code at the time thought about that as a solution.
Both email samples offer an excellent neat way of sending an email.
Whist reading about the new release I saw this updated/created page in the CRM SDK about priviledges by entity and what level of security each default security role has.
The page breaks up the priviledges by entity into these sections

The following table lists the types of privileges that are referred to from the following entity/privilege reference.

Privilege Description
Create Create a record.
Read View a record.
Write Make changes to a record.
Delete Delete a record.
Append Associate a record to another record.
Append To Associate entity record to this record.
Assign Transfer record ownership to another user.
Share Give access to a record to another user while keeping your own access.
Reparent Assign a different parent to entity record.

It’s important for people working/developing with CRM projects to understand the security model used in CRM and sometimes looking at the Roles in CRM can be a bit tricky because there is so much information to look at it’s difficult to order it, view it and understand it.

The article shows the entity privileges for each entity for the various roles go here if you want to see the list, below is a couple of examples

Account Entity Privileges

It also has a list of privileges not associated with a particular entity, an example is prvActOnBehalfOfAnotherUser.   To see the full list of these go here
I’m not entirely sure how useful these pages are but I found it useful to think about the privileges and security roles in a slightly different way than usual, to understand the security model in CRM is useful.  I hadn’t really considered the security roles as basically a way of grouping individual privileges.  Each privilege is just an individual/single privilege with it’s own guid, it then uses as an entity to group these and then a security role to group the groups.
Now I start thinking about it the security role screen does quite a good job of displaying this information and offering a gui front end to edit this information.