CRM Workflow Strategies for Business: When Does It Make Sense to Create More Than One Database In Your CRM System?
If you have been running your business and sales processes using a CRM or Contact Management system of some kind, as your organization’s needs have evolved, you may have been faced with the decision to create additional databases.
If you find yourself in this circumstance or if you have already created multiple databases, what are the considerations and potential downsides of doing so?
I will consider a handful of scenarios where it may appear that creating additional databases makes sense.
Reason #1: “Everyone Does Not Need to See All the Records” / “We Have Multiple Sales Territories and Don’t Want the Sales Reps to See Each Other’s Data”.
Is This A Good Reason??
This is not an uncommon business need – segregating or limiting access to records amongst the user base. It could be that you have people with differing job responsibilities, or sensitive data such as accounting info like “Credit Rating”, or it could be that you have sales territories and the reps are not supposed to be “poaching” from each other.
This is a poor reason to break your database into pieces. At first blush it may appear to simplify setting up territories and ensure that users will not have access to records they should not, but doing so has significant impact on your company’s CRM workflow. Don’t fall for the trap!
Most current CRM systems include tools to support limiting data access: record level access, field level access, and data views assigned to user profiles.
Record level access allows you to create rules that state who can see what records – typically applied to Accounts/Companies, Contacts, Leads, Sales Opportunities, etc. The net result is that everyone logs into the same database but each person “sees” only the records their profile defines.
Field level access is a tool to address the concern of sensitive data contained within a record. Following our earlier example of “Credit Rating”, perhaps only those in accounting should see this, or more likely, everyone can see the rating data, but only those in accounting can change its value. So, similar to the way that record level access determines access for an entire record, field level access allows your CRM administrator to define when fields within accessible records are to be veiled or read-only. The result is that your system can readily include sensitive data with the assurance that important fields do not get seen or changed by unauthorized persons.
The last tool I mention offers flexibility for an improved user experience: Custom views assigned to specific departments and users. While sometimes used as a quasi form of security, custom views help you to streamline what data is presented to your users. In other words, it allows you to remove and add fields to the primary screen(s) of your CRM system so that they fit a person’s needs when using it. Most systems will end up with a fair number of custom fields over time in addition to the fields included out of the box. A user involved with order processing most likely does not need to see all of the data relevant to a sales rep – and vice versa. Using custom layouts/screens/views allows you to give your users just what they need, but nothing more. Again, the same database file, but viewed with pre-defined “filters” that show each user strictly what they need to be more efficient.