The request sounds harmless. A sales manager wants a field to track which trade fair a lead came from. Service wants a “VIP customer” checkbox. Finance needs a dropdown for payment terms. Each one takes an administrator a few minutes. That is exactly how enterprise CRMs end up with long lists of custom fields, many half-empty, several duplicating each other, and a few that nobody can explain.

The few minutes are the cheapest part. The real cost arrives later, spread across people who were not in the room when the field was approved.

Where the cost actually goes

  • Data entry. Every field on a screen asks for attention from every user who opens it. Optional fields get skipped. Mandatory fields get filled with whatever lets the user save.
  • Data quality. A free-text field collects many spellings of the same value. A picklist without an owner keeps gaining options until it is useless for reporting.
  • Integration. If the field matters, someone will want it in the ERP, the data warehouse or the marketing platform. Each sync needs mapping, testing and upkeep.
  • Reporting. A field that half the team fills in produces reports that look precise and are wrong.
  • Upgrades and migrations. Custom fields, and the automations built on them, have to be checked at every platform upgrade and carried through every migration.
  • Onboarding. New starters must learn what each field means. When two fields look alike, they guess.

A framework for deciding

Refusing every request does not work either. People route around a CRM that cannot adapt, usually into spreadsheets, and then the data is lost to everyone. The goal is a short, consistent set of questions that every request passes through:

  1. What decision or action will this field drive? If the answer is “it would be nice to know”, stop here. A field should change what someone does or what a report shows.
  2. Does the information already exist? Check existing fields, related records and other systems. Many requests duplicate data that already lives in the ERP or can be derived from activity history.
  3. Who owns it? Name the person responsible for its definition, its allowed values and its quality. No owner, no field.
  4. Who will fill it in, and when? If the people entering the data get nothing from it, expect poor completion. Check whether it can be populated automatically.
  5. What type should it be? Prefer controlled values over free text, and a date over a checkbox when timing matters.
  6. When will it be reviewed? Set a date to check usage. If completion is low or nothing reads the field, remove it.

Keep the process light

Governance fails when it feels like a tax. Keep the request form to the six questions above. Review requests in a regular slot with one person from the business and one from the CRM team, and answer within a predictable time. Publish the decisions, including the declined requests and the reasons, so people can see the logic and stop re-submitting.

It also helps to sort fields into tiers:

  • Core fields are shared across the company, owned centrally and changed rarely.
  • Team fields serve one department, are owned by its lead and can change more freely.
  • Temporary fields support a campaign or project and get an expiry date when they are created.

The tier tells everyone how much scrutiny a change deserves, which keeps small requests fast and big ones careful.

Clean up what is already there

Most organizations already have more fields than they need. A cleanup does not have to be dramatic:

  • Export field usage: how many records hold a value, and when it was last updated.
  • List every report, automation and integration that references each field.
  • Flag fields that are rarely filled and referenced by nothing. Hide them first, wait a full business cycle to see if anyone notices, then delete.
  • Merge duplicates by choosing one definition and migrating the values.

Hiding before deleting matters. It turns a risky decision into a reversible one.

A declined request is still a signal

When a field request is turned down, someone still needed information they could not find. Sometimes the right answer is a report rather than a field, a better view of data that already exists, or a fix to an integration that should have carried the value across. Treat each “no” as a pointer to a real need and follow it up. A governance process that only blocks will be bypassed. One that redirects keeps people inside the system.