You have 0 items in your cart
Custom fields are user-defined data points you add to a CRM to capture information the software doesn’t track out of the box, from renewal dates to internal order IDs. Create one only when the data will genuinely drive a filter, an automation, or a report. If nobody will ever query it, it’s just digital clutter. Get stuck, and Act! support resources or a consultancy like Smarterbusiness can walk you through it properly.
TL;DR:
- Only create custom fields if they will be used for automation, segmentation, or reporting, avoiding unnecessary clutter that complicates the database.
- Use dropdown lists instead of free text to ensure data consistency and simplify reporting, reserving text fields for non-segmented information.
- Restrict editing permissions to administrator or manager roles and implement audit logging to maintain schema integrity and data security.
- Prefer custom tables over many fields when tracking multiple related records, such as properties or projects, to prevent database bloat and performance issues.
- Regularly review and clean up unused or underpopulated custom fields, and validate their ongoing relevance for decision-making and automation workflows.
Table of Contents
- What types of CRM data fields should you actually use?
- When should you actually create a new custom field?
- How do you name and format custom fields for consistency?
- Who should be allowed to edit CRM fields and data?
- When do you need a custom table instead of a custom field?
- What’s the safest process for creating, editing or deleting a field?
- How do you keep custom fields useful over time?
- How does Smarterbusiness approach custom fields and tables?
- Get help designing custom fields and tables
- A founder’s take on custom fields
- Sources
What types of CRM data fields should you actually use?
Every CRM offers a similar toolbox of field types, and picking the wrong one is how databases end up looking like a car boot sale. Text fields feel like the safe, flexible choice, but flexibility is exactly the problem: give someone a blank box and you’ll get “yes”, “Yes please”, “Y” and “confirmed, thanks!” for what should be one consistent value.
The main custom field types worth knowing include:
- Character/text fields for short free entry, such as a reference code.
- Memo fields for longer notes that won’t be searched or reported on.
- Number fields for counts, quantities, or scores.
- Currency fields for monetary values, always displayed in the correct currency, such as Euro (€) for Irish transactions.
- Date and date-time fields for renewals, contract expiries, or event scheduling.
- Boolean fields for simple yes/no flags like “GDPR consent given.”
- Dropdown lists for a fixed set of options, keeping data clean and reportable.
- Calculated fields, which derive a value from other fields automatically.
- Association or link fields, which connect a record to another table or entity.
Dropdowns beat free text almost every time data feeds a report or automation, because a report can’t group ten different spellings of the same answer. Reserve text fields for information nobody will ever segment by. Note also that field length limits and calculated or association fields change what’s technically possible, so map the reporting need before choosing the type, not after.
When should you actually create a new custom field?
Before building anything, ask three questions: will this data drive an automation trigger, a segmentation filter, or a compliance report? If the answer to all three is no, you probably don’t need a new field at all. That single filter saves most teams from the sprawling, forty-field monster databases we get called in to untangle.
Common anti-patterns worth avoiding:
- Building a field for a one-off task, like a single campaign that ran once in March and never again.
- Duplicating information that already exists elsewhere in the record under a slightly different name.
- Creating a “workaround” field to patch a broken process instead of fixing the process itself.
- Editing a standard system field to repurpose it, which risks breaking reports and integrations that rely on the original.
Where possible, lean on tags, groups, or existing categorisation structures rather than reaching for a new field every time. A CRM data model that grows without discipline becomes a haystack with the needle buried somewhere nobody can find it. If you genuinely need the data for decisions, build the field. If you’re not sure, wait a month and see if the question comes up again.
How do you name and format custom fields for consistency?
Naming discipline is the difference between a database that ages well and one that becomes an urban legend (“nobody knows what Field_47 means anymore, but we’re scared to delete it”). Separate the internal field name from the label users actually see, and keep both predictable.
A workable sequence for setting up a new field:
- Pick a clear internal name with a consistent prefix, such as
CF_RenewalDateorCF_ContractValue, so custom fields are instantly recognisable in a list of hundreds. - Write a user-facing label in plain language, matching how your team already talks about the data.
- Apply a format mask where the entry pattern is predictable. Symbols like
#for digits,@for letters, and%for a fixed pattern enforce consistency at the point of entry, which is far easier than cleaning data after the fact. - Set a sensible default value so blank fields don’t skew your reports.
- Add help text or an example directly on the field, so a new starter isn’t guessing what “Renewal Tier” means on their first week.
Pro Tip: Build one master dropdown list for anything that repeats across multiple fields, such as industry sector or lead source, then reuse that same list rather than recreating a slightly different version each time. One inconsistent dropdown is annoying; five inconsistent versions of the same dropdown is a reporting nightmare.
Who should be allowed to edit CRM fields and data?
Schema changes are not a job for whoever’s nearest the keyboard. Restrict the ability to create or edit fields to Administrator or Manager roles only, and treat that permission the way you’d treat a spare key to the server room. It’s not about mistrust. It’s about the fact that one accidental field-type change can quietly corrupt months of data before anyone notices.
Governance basics worth locking in from day one:
- Limit visibility of sensitive custom fields, such as salary bands or medical notes, to the roles that genuinely need them.
- Turn on history or audit logging so every field change generates a traceable record of who altered what, and when.
- Back up the database before any schema change, and schedule it for a quiet maintenance window rather than the middle of a sales team’s busiest afternoon.
The stakes here are real: creating or editing custom tables locks the database while the change is applied, so every other user needs to be logged out first. Skip that step and you risk corruption, not just an error message.
When do you need a custom table instead of a custom field?
A single custom field works when there’s one answer per record. A custom table earns its keep when there are many. Think of a letting agency tracking multiple properties per landlord, a consultancy logging several projects per client, or a supplier managing a rolling list of contracts per account. Bolting twenty “Property 1, Property 2, Property 3” fields onto a contact record is the CRM equivalent of stacking filing cabinets in a hallway. It works until it very much doesn’t.
Custom tables store one-to-many, spreadsheet-style data linked back to a contact or company, and several platforms ship with prebuilt industry templates that set sensible default columns and layouts from the start.
| Consideration | Single custom field | Custom table |
|---|---|---|
| Best for | One value per record | Multiple related records per contact |
| Pricing shape | Included in standard field allowance | Often bundled with premium or add-on modules |
| Standout | Fast to set up | Handles complex, repeating data cleanly |
Scope decisions deserve real care here. When creating a custom field set, the scope you choose can be irreversible, affecting where it appears and whether it’s searchable later. Get it wrong and you may be rebuilding rather than editing. Linking too many entities to one custom table also drags on performance, so scope generously enough to be useful, not so widely that every record on the system tries to pull from it.
What’s the safest process for creating, editing or deleting a field?
Treat schema changes like minor surgery: plan first, then move carefully. Skipping the preflight checks is how a five-minute task turns into a weekend recovering lost data.
- Back up the database and confirm every other user is logged out before starting.
- Create the field with its correct type, name, and length.
- Customise its behaviour, including default value, format mask, and any validation.
- Set triggers or automation rules if the field will feed a workflow.
- Add the field to the layout so users can actually see and populate it, since a field that exists but isn’t on the layout might as well not exist.
Two warnings are worth repeating to anyone with schema access. First, changing a field’s data type can permanently wipe existing data in that field, so migrate values to a new field rather than converting an existing one on the fly. Second, deleting a field is usually final. Confirm your backup restores cleanly before you touch delete, not after.
How do you keep custom fields useful over time?
A CRM is a living thing, not a filing cabinet you set up once and forget. Pilot any new field with a small group first, watch whether people actually populate it, and adjust the label or format mask if the fill rate is patchy.
Ongoing maintenance worth scheduling:
- Run a periodic clean up, archiving or deleting fields nobody has touched in the past six months.
- Check reporting regularly to confirm fields are populated consistently enough to be trustworthy.
- Review which fields feed automations, since an empty or inconsistently filled field can quietly break a trigger without any error message.
- Watch performance if a custom table is linked to a large number of entities, since over-linking slows the system down for everyone.
Pro Tip: Set a quarterly reminder to pull a simple fill-rate report on every custom field. Anything sitting under 20% populated after six months is either badly named, badly placed on the layout, or simply not needed. A CRM reporting dashboard makes this kind of health check quick rather than painful, and pairs well with the kind of automated reporting workflow Gainable’s guide describes for turning custom data into recurring sales reports.
How does Smarterbusiness approach custom fields and tables?
Fields should mirror how a business actually runs, not what the software happens to ship with by default. That’s the principle behind every implementation Smarterbusiness has delivered since 2014: discovery first, then data mapping, then naming standards, then testing, then training, in that order, never reversed.
Most of the CRM chaos we get called in to fix isn’t a software failing. It’s fields and tables built to solve a problem for one afternoon that quietly outlived their purpose. Getting the naming and scope right at the start saves months of untangling later.
Founder Patrick Lennon built the consultancy on decades in sales, marketing, and operations, not software sales, and Smarterbusiness holds certified Act! CRM consultancy status specifically for this kind of hands-on schema work with SME teams.
Get help designing custom fields and tables
Smarterbusiness fixes the CRM sprawl this article warns against, because that’s the actual job: mapping fields to real business decisions instead of letting a database grow field by field until nobody remembers what half of them do.
Where a generic software reseller sells you a licence and leaves you to figure out field design alone, Smarterbusiness sits alongside your team through discovery, naming standards, custom table setup, and staff training, all tailored to how your business already operates rather than a generic template. Services cover custom field design, custom tables for one-to-many data such as properties or contracts, full Act! CRM implementation, and ongoing support once the system is live. If your database has drifted into the kind of mess this article describes, or you’re starting fresh and want it built properly the first time, book a CRM training session or get in touch for an implementation audit and a straight quote.
A founder’s take on custom fields
The best custom field setups we’ve built started small and earned every addition later. The worst started with a wish list of forty fields nobody had actually tested against a real report. Minimalism isn’t about being precious. It’s about only building what a decision, a filter, or an automation genuinely needs.
If you’re weighing up a build and want a second opinion, or want examples from a similar industry, get in touch. We’re happy to talk through it.
— Patrick Lennon
Sources
- How do I Create and Edit Fields in Act! CRM
- How to create and edit custom tables
- Custom Industry Tables – Act!
- Creating custom fields — CiviCRM documentation
