The Field You Add Today Is The Migration You Pay For Later | Zoho CRM Custom Fields

Adding a custom field in Zoho CRM takes about eleven seconds. Removing one takes a conversation with everybody who built a report, a workflow or an integration on top of it.

That asymmetry is the whole subject. Nobody ever decided to have four hundred fields. They added one at a time, each for a good reason, and the bill arrived years later disguised as a migration.

Everything on screen is a mock demo of Zoho CRM with sample data.

Setup, Customization, Modules and Fields. This is the ledger. Every module you have, and inside each one, every field somebody added. There's no cost column, which is part of the problem — the screen presents a field you use daily and a field from a campaign that ended in 2023 as exactly the same kind of thing.

Open a module and the list is usually longer than anyone expects. Not because someone was careless, but because a field is the cheapest possible answer to "can we track this?" — and it's always yes.

Here's the line we use, from our own readiness work. Anything under ninety percent populated is not ready.

That's not a data-hygiene preference. Zia's predictive scoring learns from your closed-won and closed-lost history, and it will faithfully score against whatever patterns exist in the records you actually filled in. A field that's half populated doesn't give you half an answer. It gives you a confident answer built on the half of your business that happened to get typed in.

Now the screen almost nobody opens. Same page, tab across: Global Sets. A global set is one list of picklist values, defined once, reused everywhere. Define your regions here and every module that needs a region points at the same list.

Skip it, and each module gets its own picklist. Which is how you end up with fourteen spellings of California — CA, Cal, California, Calif, all of them typed by somebody being helpful. Every one of those is a separate value as far as a report is concerned, and as far as an agent is concerned.

Our position on this is plain: use picklists instead of free text on anything you will later want to group by. And define the picklist once.

Back in a module's field list, here's the failure that costs the most and shows the least. A workflow rule can still fire on a field nobody populates any more. The campaign ended, the field decayed, the rule kept running — quietly, correctly, on nothing.

And this is the part worth remembering: a broken integration raises an alert. A decayed field does not. Nothing in the product will tell you. The rule reports success every time, because firing is all it was ever asked to do.

So what do you actually do about it. Take your top twenty fields — the ones your reports and automations depend on. Check the fill rate on each. Then find who owns each of those fields, by name. Not a department. A person.

That last step is the one that gets skipped, and it's the one that holds. A field with an owner gets retired when it stops being useful. A field owned by "sales ops" lives forever.

Before the audit, one thing about field types, because this is where the damage is decided. A single-line text field will accept anything. That's why it's the fastest choice and why it's almost always the wrong one for something you will later want to count.

A picklist constrains the answer. A lookup points at another record, so the relationship is real rather than retyped. A formula field derives its value and cannot drift.

The decision takes a few seconds at creation and is close to permanent afterwards, because changing a text field to a picklist means deciding what to do with every value already in it — and there are always more distinct values than anyone expects.

So the rule is simple. If you will ever group by it, filter on it, or report on it, it is not a text field.

And here's the part that makes a field different from any other configuration choice. A field is a schema change. The moment it exists, it can appear in an integration payload, a report column, a workflow condition, an imported spreadsheet, a form on your website.

Which means removing it later is not a question about the CRM. It's a question about everything attached to the CRM, and the honest answer is usually that nobody knows what's attached any more.

And here is the part that makes the word "removing" a little generous. You largely can't. Take a field off a layout and Zoho moves it into a section called Unused Fields. The data is preserved — which is the right default — and the field still counts against your field allowance. The slot does not come back.

So the honest accounting is that a field is close to permanent from the moment somebody says yes. Not hard to hide. Hard to be rid of.

That's why estates end up with four hundred fields and no confidence about any of them. Not carelessness. Just an accumulation of small yeses, none of which had a cost visible at the time.

The fix isn't discipline about saying no. It's making the cost visible when the question gets asked.

None of this is glamorous and all of it decides whether the expensive things you buy later actually work.

We run this as a field-level audit, and we scope it before we start. If we estimate it low, we absorb the difference.

CodeStringers. Zoho authorized consulting partner, Santa Cruz.