Optics manufacturer centralizes and optimizes data flow using Zoho CRM

Solution

Features in use

Data modeling

The customer enlisted the assistance of Zoho CRM's Migration team to set up their data model and ease the transition from Salesforce. The process involved creating modules for each corresponding table and setting up fields in each module to map existing data. They also took care to ensure the advanced properties of fields also matched, such as the lengths of string type fields. A mismatch in one place could cause incompatibility in the import stage or cause data loss if forced. They also set up conversions and conversion rules in this phase and tested them with sample data to ensure transitions and the data flow were functioning as expected.

Workflow automation

With the foundational work of module set up completed and tested, the construction of the automation framework could begin. The first building blocks to be placed were the workflow rules, as these are the smallest individual units of automation. Once these were in place, work proceeded on blueprints. The first blueprint to be set up was for the Leads module, to ensure smooth stage transitions as potentials were researched and moved along the pipeline. The end of this stage involves conversion to contacts, deals, and accounts—but since the conversion mapping was already implemented and tested, it was ready to go. The deals blueprint was next on the list, serving to enable deal flow through the various stages of the pipeline. Having a blueprint for this process enables the creation of buttons for stage transitions within record views and avoids accidental updates to the wrong stages.

With blueprints completed, the next order of business was to provide ways to create sales orders, which the company accomplished by creating a custom button in the Accounts module, which would lead to a kiosk—which would then activate a custom function. In this chain, it made most sense to start from the bottom up, as the lowest step was the one with no dependencies. As the lowest step, the function forms the core of this flow and creates a new sales order record that has the correct lookups linked to accounts, products, and promotions.

The kiosk forms the wrapper and UI around this function, asking the user to enter product names, quantities, and promo codes—all of which are then fed to the function so it can create a sales order with the aforementioned details and lookups. The final piece of the puzzle was the custom button that activates the kiosk and ultimately the function. The placement of the button meant it also collected the account record's information without requiring that it be entered first. Thus, they successfully configured the data flow from accounts to sales orders. As conversions had already been mapped, data could then flow freely from sales orders to invoices through conversion.

Data import

The customer already followed a policy of backing up their Salesforce CRM data to a database daily. This simplified the transfer process, as it enabled them to simply export the database tables to CSV files and then upload each table to the corresponding configured module in Zoho CRM. Then they needed to map each column of their CSV file to the correct field in the Zoho CRM module. This step was crucial, as any incorrect mapping could lead to data in several linked modules being corrupted. Care was taken to ensure each incoming field was mapped correctly to its intended destination module in Zoho CRM.

Regular data backup

The customer required that all data from Zoho CRM be exported every day to their mainframe, which they could accomplish manually by exporting each module. But a more efficient way of doing this would be to use the bulk API call for Zoho CRM, whereby a script running on the customer's hardware could periodically hit the Zoho Bulk GET API to obtain the data without human intervention. It could then perform follow-up actions, such as moving the data to an SQL server. The required API call for this would be the bulk API, rather than the standard CRM CRUD. This saves time, processing resources, as well as API credits in Zoho CRM. It also guards against the human error that inevitably comes when performing an action several hundred times a year. A single bulk API call only takes one API credit despite pulling several thousand records.

Regular data updates

The customer needed to move data from an SQL database back over to Zoho CRM and update whatever data is out of date there. Similar to the previous step, they fulfilled this requirement by using a bulk API call, taking daily records from SQL, exporting them to a suitable format, and then pushing these via the bulk API call to Zoho CRM once again using a locally run script on the mainframe.

Reports

The company needed not only to create reports on the Invoices module, but also to include fields from other related modules—namely, Accounts, Sales Orders, and Promotions. They accomplished this by using Invoices as the starting module when creating a report, then adding other necessary modules as parent modules. Since these modules were linked through lookup fields, this solution was both possible and efficient.

All required modules can be added as parents while creating a report on the Invoices module.

In the Columns screen, we can see that fields from all four modules are available, leaving us free to choose any field to display, group, and filter by.

User permissions

The company handled user permissions using the profiles feature to set up a separate profile for sales executives and one for users who make reports with specific data. The company also wanted to handle access to reports on a granular level, which can be accomplished on a case-by-case basis using folder access privilege settings and creating reports in the folders with the correct access privileges set beforehand. Changing access to a report can be as simple as cloning it to a different folder with different privileges.

Here, we can see permissions to create reports being granted only to users with the Analyst profile—all other privileges being the same. Though sales users have view access, they can only view reports to which they have access. The report itself will need to be made available to them specifically or to the whole organization before they can view it, which shows that report view permissions can be handled granularly at the folder-level.

UI customization

The customer also needed to have different UIs for different types of users. The home page was customized based on profiles, which were already set up for prior requirements and then customized to match the requirements for each user type. In order to add visual elements to home pages, they first created a dashboard using data relevant to each role, and then created chart elements. Additionally, they made custom views for each relevant module and role. These were then added to the custom home page for each role, in the relevant order, and then assigned to their respective roles and rolled out.

The Sales home page details the leads, accounts, and sales orders owned by the salesperson currently logged in. It also displays a graph of new accounts charted week over week.

In contrast, the Analyst home page deals entirely with summary stats rather than individual records. It shows trends for various metrics, enabling analysts to pinpoint anomalies immediately that they can then explore further.