Security: Empowering Your Users Within CRM | npENGAGE

Security: Empowering Your Users Within CRM

By on Jun 25, 2013


In my 5+ years at Blackbaud, I have had more conversations with customers about security and user access that I can count. On top of that, I’ve seen security models that cross the spectrum. Regardless of the customer, the CRM solution they are using, or the nature of the users, there are two themes that continue to resonate in conversations about end-user security that simply serve as barriers to maximizing the use of your CRM.

Theme #1: “Our users are out to maliciously harm our database.”

Okay, I’m exercising some creative license there. But when I hear customer requirements surrounding end user security, this is basically what I am hearing. “Of our 300 users, only three can update addresses because the others might do it wrong.” Key word there…MIGHT! More often than not, database security has been implemented out of an abundance of caution of the mistakes that people might make. Your users are competent people – if they weren’t, they wouldn’t be working for you. I’m not advocating that everyone should be able to do everything, but it’s time to evaluate your security settings and determine if they really make sense. Most CRM solutions today have mechanisms in place that allow you to see when a record was last change and by whom, either through native tools or through query. Some even go so far as to provide you a rollback mechanism to revert incorrect changes. Let your users do things that make sense. And, if someone is repeatedly introducing bad data, address it with that individual, don’t penalize the entire user community. Which brings me to theme #2…

Theme #2: “We should use security to solve people problems.”

Most databases have security roles or groups that govern security. But, customers I speak with often have deviated from their standard security model to limit security for one particular user. This user might have the same job as six other people, but because of ongoing data issues with them, their security has been modified to prevent them from doing specific things. Security settings should be built for the job role that someone has, not to their own ability level. To be blunt, if their security needs to be modified because thy are unable to effectively do certain tasks that their job requires, perhaps they shouldn’t be doing that job. You shouldn’t necessarily just go and terminate staff members that make data entry errors, but you also shouldn’t come up with a user-based security model as your solution. I often discover in these instances that there is no proper training program in place, and no remedial training offered to the user when they are making the errors. Give your users the benefit of the doubt. Ensure that they are properly trained and have the appropriate resources, such as a policies and procedures guide, at their disposal. If you’ve done all you can to ensure that they know how to properly enter data, then perhaps it’s time to consider more drastic alternatives. But don’t simply jump to modify their security at the user-level. It does nothing more than introduce larger issues into your database.

Ensure that your users have access to the tools to do their job effectively. They’ll thank you for it, and your CRM data will be more accurate and up to date.


Leave a Reply

Your email address will not be published. Required fields are marked *