cancel
Showing results for 
Search instead for 
Did you mean: 

CRM 2011 Field Security

Author Name: Matthew Wittemann

Field Level Security is great in CRM 2011, but it would be great to have it available on system fields as well.

Status: Completed
Comments
Administrator
Status changed to: Completed
 
Administrator
Thank you for your suggestion. From your description, we believe this functionality is already on a list of enhancements being considered for future releases. http://connect.microsoft.com/dynamicssuggestions/feedback/ViewFeedback.aspx?FeedbackID=640936 Please vote for that suggestion if it depicts the same idea. Best regards. This posting is provided "AS IS" with no warranties, and confers no rights.
Administrator
very good
Administrator
This really is a frustrating gap in the features of CRM. The other suggestion managed to get 244 votes before being closed as "Resolved" (with no explanation of why that is, since the issue remains in CRM 2013). http://connect.microsoft.com/dynamicssuggestions/feedback/ViewFeedback.aspx?FeedbackID=640936 So if you voted for the previous one, vote again for this one here.
Administrator
I do think Microsoft needs to fix the issue of not being able to enable the Field Security on the old field and then not being able to CREATE A NEW EMAIL FIELD without disabling the security field. That defeats the purpose of having admin rights and giving a certain person field security privileges, which I cannot if the field security button is not ENABLED.
Administrator
Over 200 votes, more than three years waiting for this to be addressed despite two major releases and another in the works. Do Microsoft have any news for us on this? I can easily accept that some system fields should not support this as they impact built in functionality (certainly anything that is not customisable, and is system required, such as created/modified on/by, Owner, etc). Even being able to do it on some key entities would help such as Account, Contact, Lead and Case would be a good start. Maybe Opp>Q>O>Invoice too. Perhaps a good middle-ground to avoid some of the most obvious issues that might affect OOB functionality would be to allow field security to be configured on system fields, but always enable them for Read. In other words, allow us to configure them to restrict create and write, but always allow read to make sure things don't break. (eg: If Address1_Name were not readable by a user, they could not use the built-in feature to add an address to a Quote, as that relies on this field to filter the results). This could be achieved by having a self-configuring profile rather like the System Administrator field security profile, that always adds all secure fields and grants read access, and is associated with all users, and cannot be modified. This approach would mean some additional code at the point of configuring a field for FLS, as an extension to the code used for System Admin profile, but *no* additional code would be needed at the "point of use" when a user interacts with a form it would apply the regular logic to this to see that they do have read access to the secured field via the profile(s) they are linked to. It should also reduce the testing required to deliver this.
Administrator
And nearly 300 on the one referred to by MS and now marked as "Resolved - Tracking".
Administrator
Administrator
This feature is now in the product. Thank you!
Administrator
Based on publicly available information, this feature will FINALLY be available in CRM 2015!
Labels