CRM Workflow Strategies for Business

Do you keep more Than One Database? 

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 Multiple Sales Territories and Don’t Want the Sales Reps to See Each Other’s Data.”

Also Read: 14 Marketing, Salesforce Tactics That Will Help You Win

Is This A Good Reason??  No.

This is not a unique 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. My Reasons:

This is a weak 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 a 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 required fields do not get seen or changed by unauthorized persons.

The last tool I mention offers flexibility for 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.

Also Read: CRM system can be streamlined using

In the next post in this series, I will share some of the negative – and often unforeseen – side effects and processes that get broken when you split a CRM database into pieces…