When it comes to the security roles I like to use roles based on a functionality instead of based on business roles.
In most companies employees with a similar business roles are allowed to do different things in the MS CRM system. Making exceptions is hard when you use role based security roles. Functionality roles on the other hand can be easily combined to create the right level of authorization.
A functionality based role can be, ‘Maintain Accounts’. A user with this role is allowed to read, write, append, append to, share and assign accounts on Business Unit level. Combined with ‘Maintain Contacts’ or ‘Create and Delete Account’, etc, gives a complete set of functionality.
Next to these clear functionality roles a user needs in general a basic role to be able to use the MS CRM basic functionality. For example the ‘Set Regarding’ functionality to link a email to a record in MS CRM.
When designing the basic use role I came across some oddities I couldn’t directly explain. Users with the basic role should be allowed to use the ‘Set Regarding’ functionality, but for some reason I couldn’t get it to work. So I created a new organization with 1 custom entity and puzzled until I found the minimum rights to use the ‘Set Regarding’ functionality.
That’s when I came to the conclusion you must have read rights on Account, Contacts, Leads and Opportunities, to regard an email to a custom entity.
I put the complete set of rights in the pictures below:
Minimum rights to use Set Regarding
(1 votes, average: 2.00 out of 7)
Loading ...Querying on checkbox values
Via the Advanced Find it is very easy to query on all kind of things within MS Dynamics CRM. The functionality is great. The only thing is, it does not always give you the right result. This has nothing to do with the Advanced Find functionality but everything with understanding the underlying Microsoft SQL Server Database.
If you use a bit (checkbox) value, you can assume there are only two values: YES and NO. But this is incorrect. In the database 3 values can be used for a bit value: YES, NO and NULL. On the forms in CRM the NO and the NULL are perceived the same, both as NO. When you query a checkbox, with the query ‘Checkbox Equals No’, you will only get the records where the bit is actually NO. The records with a NULL value in the database are not included in the result. In case you want the NO and the NULL values, you can better query ‘Checkbox Does Not Equal Yes’.
In other words I recommend to query always on the positive (YES) value when querying a checkbox.
So I recommend ‘Checkbox Equals Yes’ and ‘Checkbox Does Not Equal Yes’.
(No Ratings Yet) Loading ...Read-only fields on forms are not read-only
Fields in Microsoft Dynamics CRM 4.0 cannot be set to read-only!!!
Ok, a little explanation and a demo script to show what I’m implying.
Yesterday a customer asked me to change the text in a read-only field. I’m system administrator on their system, so the easiest way should have been to change the Field Properties of the attribute, but this would allow all users to change this attributes on all records.
Another option would be to use the Enrich Functionality.
I tried a third option, triggering javascript via the Address Bar of Internet Explorer. The usage may be well know, but I never thought of using it to modify read-only fields on records. Well, it is surprisingly easy. All you need to know it the id of the attribute you want to modify. (The id can be found with something like the IE Developer Toolbar.)
If you have the id the code is easy and you only have to copy it into the address bar of the record you want to modify:
javascript:crmForm.all.new_attribute.DataValue = "read-only doesn't work for me"; crmForm.all.new_attribute.ForceSubmit = true; crmForm.Save();
This means every user with modify rights on a record can change read-only field on that record.
I still have to test this in Microsoft Dynamics CRM 2011 in combination with field-level security.
(1 votes, average: 5.00 out of 7) Loading ...
4.0 Implementation Guide
