Zoho CRM – Data Structure Essentials

In my forty-plus years of system development and implementation, I have as yet to see a client excited to discuss how their data is or will be structured. Their indifference is a shame because how data is structured controls what the application can do and how difficult or easy it is to achieve the organization’s goals.

Before getting into the nitty-gritty, let me cover some frankly dull stuff. Regarding notation, throughout this paper, I am referring to CRM’s modules when I capitalize, for example, Accounts vs. accounts. I may use the notation of Module.Field when I refer to a field in a module.

Also tedious but essential are a few words about how data is structured for computer applications, including Zoho’s apps. The notion that data has structure goes way back, even before the advent of electronic calculators. Suffice it to say, current theory and practice categorized data into entities, relationships, and attributes. Entities are the nouns of our data universe. More often than not, entities represent tangible things. Customers, orders, line items, quotes, leads, these are all entities. In CRM, almost all the modules represent them. 

Relationships are places where entities link to each other or JOIN in the parlance of SQL. Customers have orders. Orders have line items. Line items (usually) have product codes (a link to the Products module). There are three kinds of relationships, one-to-one, one-to-many, and many-to-many. The most common of these is the one-to-many relationship. Orders and line items are a good example. An order can have multiple line items, while a line item can only belong to one order. In CRM, the Lookup field is what establishes the potential for a one-to-many relationship. The module that has the Lookup field is a child to the module that is looked up. Subforms, in particular, the Line Items in modules such as Invoices or Quotes hold related records.

There is a critical difference between records that are related via the Lookup field and records that are related via Subforms, and this has to do with our inability to report on Subform records. For example (albeit somewhat silly) suppose you wanted a report to show invoice line item quantities in order from the largest to the smallest. There is no way to do this. Subform records are not directly accessible in Reports, they are not accessible in Analytics. The only way to get at Subform records is by way of Deluge functions. This may not be important when dealing with the installed modules, Invoices, Quotes, Sales Orders, etc., but there may be huge implications when you are creating custom modules. If you need reporting access to the child records of a module, do not place them in a subform.

Last but not least, come attributes. Attributes are the stuff of entities, first name, order number, quantity, etc. Structurally, attributes have no impact on CRM, but this is not to say you should not be careful in choosing which type of attribute, phone, date, single line, etc. when you add them to a module.

If you have not reviewed Zoho’s list of standard modules and fields, at some point, you should do so. The list can be found here.

Modules

As I’ve mentioned before, modules represent your CRM’s entities. (If I come across any exceptions, I’ll point those out.) The modules I will be focusing on are Leads, Contacts, Accounts, and Deals. These are the core entities in any sales system. Structurally, modules contain fields (most of which are attributes) and subforms. Subforms are a particular way of representing one-to-many data, where each subform item is a child of the parent module. As I mentioned before, modules can be linked to or related to other modules using the Lookup field or a Multiple Lookup field.

Leads

Its name is apropos. Leads should be thought of as a lightweight thread, a filament even, leading to a real person with whom to initiate the sales process. I often find clients junking up the layout with fields that don’t support the module’s intent, getting the contact. A lead can be as atomic as an email address or more robust with a first name and phone number. It should tell you its source and how it has been utilized in your sales process. Both these things come with CRM’s standard layout, so if you find yourself adding fields you should step back and ask yourself, is this really where this data belongs. I don’t suggest you shouldn’t be adjusting some of the existing fields, such as Lead Source, to meet your particular sales process needs, But if you start adding bill-of-materials info, watch out!

Deals

You can think of CRM modules having primarily one of two purposes: storing data or managing processes. Deals fall in the latter. Properly used, a deal should assist a salesperson through the tasks of taking a contact, from what was a lead, to making the sale (or closing the deal as it were). Its other purpose is to help manage revenue projections for analysis of the efficacy of various sales processes, as in which lead types produce greater revenue.

Unlike Leads, Deals must often be overloaded with data found in another table in a strict data relational model world. I recently integrated Zoho Forms, Zoho Sign, and CRM in an application where salespersons sent documents for an e-signature in part of the deal process. The documents contained information that was submitted by potential clients in a Zoho Forms form. In a stand-alone application, I would have never duplicated the form data in the Deal module, but CRM, in many cases, doesn’t allow us to reference fields from related modules in its workflows. In this particular case, the Zoho Signature integration only allowed me to pass Deal module data to Signature when sending a document for e-signature. 

Accounts

The Accounts module in CRM is probably one of the most misunderstood modules in the system. If it is needed it, is often misnamed, and if it isn’t needed, it’s kept around. What do I mean by this? To begin, let’s dig into what the Account module is really for. It may seem obvious but given the number of times I’ve seen it abused, perhaps not so. 

An account represents a non-human entity that is central to the sales process, where there is a sales relationship between you or your company and an organization. In this case, an organization can be a company, a church, a family household, or a club. At its core, an account represents two or more individuals that may have different roles that are of significance in your sales process. 

Some sales processes depend on Accounts, and some don’t. Retail stores, for example, do not use accounts. Somebody comes, they browse around, they buy something, or they don’t. Manufacturers, on the other hand, almost always need Accounts because, while they deal with individuals, ultimately sales are associated with a company or organization of some sort. You need to decide who you sell to. You may have a situation where you sometimes need the Accounts module, and sometimes you don’t. Whether you do or not must be reflected in related modules, such as Quotes or Invoices, in that you may want to make your Account Lookup in those modules required, or not.

One of the issues with Accounts I’ve encountered is where my client is uncomfortable having an account record exist before selling them anything. In one particular instance, their logic went like this; I want to rename Accounts to Customers, and customers can only be folks I’ve to whom I’ve sold. This misapprehension required me to make extensive back-end modifications to ensure CRM did not create an Account record until after a salesperson made a sale. Let me reiterate; an account is not a person; it is not a customer. The Account module enables you to define a collection of two or more contacts related via an organization, business, or some other uniting factor.

Contacts

Many people consider Leads and Contacts as synonymous. I think this is a mistake. Contacts are known entities; leads are not. Your salespeople will have gone to some effort following up on a lead, identifying and realizing them from perhaps just a phone number into a living, breathing person with whom they can do business. Leads are anonymous; contacts are not.