Field level security has been a
All it takes is, creating a custom field, enabling field level security on it, creating at least one security profile for the field, setting the create, edit, read levels on the field in the profile, putting that field on a form and Poof! Field level security. I know that is a fast go through but it actually is fairly simple to do.
You can group users into different security profiles and have each secure field have different edit and read options. This means you can have a field with important info for your managers that the other users can't see. Or you can have a field that managers can read and update but standard users can only read.
And this security carries over to views and exports as well. Let's say Shep is a sly user and pretty good at getting data out of CRM. So he puts one of the secured fields into a view and exports the view to Excel. He still can't see it. "Rats!" He says. So he decides he is going to export the data and check the box that formats it for re-import. Once he opens it in Excel, he puts values he knows in the secured field and uses the most awesome import tool to import the data back into CRM. He checks the status of the import and sees there were partial failures. On review of the import log he sees the message "You do not have update permissions for the secured field." He says "Double Rats!" we say "Foiled again! You sly dog!" This means the system knows, based on the security profile of the field that he is not someone that can read, create or update that field. Nice!
So as you can see, I am a fan. Not only of the functionality but, I have to admit, at its ability to foil the sly dog that sometimes lurks in our cubicles. I hope this is just one more thing that will encourage you to try out CRM 2011. Enjoy!
by Paige L. Cassada,