NetSuiteFree worksheetPDF, Excel, Word exportNetSuite

NetSuite Custom Field Specification Worksheet

Custom fields multiply quietly. Without a spec, the same idea gets built three times under different IDs. This worksheet lets an admin or developer plan every field in one table, agree it with the business owner, and export to Excel as the build list.

Download:

Field label	Field ID	Field family	Type	Applies to	Populated by	Mandatory	Business owner

Fields planned

NetSuite prefixes script IDs by field family: custentity, custbody, custcol, custitem and custrecord. Keep IDs short, lowercase and stable because scripts, saved searches and integrations reference them. Confirm the type options against your account, since available types depend on the field family.

Keep the spec and account in sync

Optional: ask how a read-only metadata view of your NetSuite account could keep documentation current.

Optional. The tool and every export work without this. No spam.

How to use the worksheet

Add one row per field. Fill the label first, then choose the field family because that decides the ID prefix and where the field can appear. Record who owns the field and how it is populated. A field filled by a script or integration needs a different review from one users type in. Export to Excel and use it as the checklist while you create the fields, then keep it as your data dictionary.

One row per field per family
Record the source so you know what breaks when an integration changes
Name a business owner for every field
Mark mandatory fields carefully, since they affect imports and integrations

Naming and ID conventions

NetSuite builds the full ID from a prefix and the suffix you type, for example custbody_contract_ref. Pick a team convention before you build: lowercase, underscores, no abbreviations that only one person understands, and no dates or version numbers. Scripts and saved searches refer to the ID, so renaming later is expensive. Use the label for the human wording and keep the ID about the data.

Common mistakes

The usual problems are creating a free-form text field where a list would enforce clean data, making a field mandatory and then breaking CSV imports or web service integrations that do not send it, and applying a field to every record type when only one needs it. Also check whether a standard field or an existing custom field already holds the information before building another.

Free text where a list or record type would prevent typos
Mandatory fields that block integrations
Applying fields to all subsidiaries or roles by default
Duplicate fields with similar labels

Frequently Asked Questions

What are the custbody, custcol and custentity prefixes?

They are the ID prefixes NetSuite uses for custom transaction body fields, transaction column fields and entity fields. Item fields use custitem and custom record fields use custrecord. The prefix is added for you when you save the field.

Can I change a field ID later?

You can edit the suffix in many cases, but scripts, saved searches, workflows and integrations that reference the old ID will break. Treat the ID as permanent and plan it in a spec like this one before creating the field.

Should I use a list or free text?

Use a list or record type when the value comes from a controlled set, because it prevents typos and supports filtering. Use free text only for genuinely open values such as a customer reference number.

Does this replace the account's field list?

No. It is a planning and documentation tool. The account remains the source of truth, so reconcile the worksheet against the custom field list in NetSuite periodically.

If you maintain hundreds of custom fields, Netray can help build a read-only view over your account metadata so the spec and the account stay in sync.

Talk to an Expert Explore More Free Tools

Related Tools

NetSuite

More NetSuite tools

See all

Back to All Tools