NetSuite Custom Field Metadata Tables Explained
Map NetSuite custom-field families to SuiteQL metadata records: custom-record fields versus transaction, entity, item and CRM definitions—always verified in the Records Catalog.
NetSuite does not expose one universal “all custom fields” SuiteQL table. Custom fields are split into families, and each family may appear as a separate analytical record—or not appear at all—depending on account features, role and analytics channel.
This overview sits beside How to Query NetSuite Custom Record Fields With SuiteQL. It explains which metadata surface to search, not how to pull instance values.
Names in this article are common search targets and illustrative labels. Confirm every analytical record and column in Setup → Records Catalog under the SuiteScript and REST Query API channel for the execution role. Absence of a name does not mean custom fields are missing from the account; it means that family is unavailable to SuiteQL in the current context.
Metadata versus instance data
| Layer | Purpose | Example shape |
|---|---|---|
| Field-definition metadata | Which fields exist, labels, types, ownership | Catalog records for custom-field families |
| Type / list definition metadata | Custom-record types, custom lists as definition objects | Catalog entries for types or lists when exposed |
| Instance data | Values on real rows | customrecord_..., transaction, customer, and so on with cust... columns |
A metadata query answers “what is defined?” An instance query answers “what is stored?” Do not mix the two when debugging empty results.
Field families you should search separately
Oracle’s customisation model (and the catalog) separates families. Typical search phrases when hunting definitions:
| Family (UI concept) | Why it is separate | Illustrative SuiteQL search ideas |
|---|---|---|
| Custom-record fields | Belong to a customrecord_... type |
CustomRecordCustomField, custom record field, a known custrecord_... |
| Custom-record types | The type definition itself | CustomRecordType, custom record type, a known customrecord_... |
| Transaction body fields | Header-level transaction custom fields | Search transaction custom field / body field terms and known custbody_... IDs |
| Transaction column (line) fields | Line-level custom fields | Search column / line custom field terms and known custcol_... IDs |
| Entity fields | Customer, vendor, employee and related | Search entity custom field terms and known custentity_... IDs |
| Item fields | Item record custom fields | Search item custom field terms and known item field script IDs |
| CRM fields | CRM-oriented custom fields | Search CRM custom field terms and known CRM field script IDs |
| Other-record fields | Fields applied to other standard records | Search by the parent record and the field script ID |
Exact analytical record script IDs vary. Global Field Search on a known script ID is often faster than memorising family table names.
How the Records Catalog fits
- Sign in as the role that will run SuiteQL (or
N/query). - Open Setup → Records Catalog.
- Choose the SuiteScript and REST Query API channel—not a channel aimed at another product surface.
- Search by family name and by a concrete field script ID.
- Enable Show Unavailable Items when something is missing that you expect from the UI.
- Record the analytical script IDs and joins in a private schema note.
General catalog technique is covered in How to Find SuiteQL Table and Field Names.
Custom-record family in more detail
For custom records, keep three concepts distinct:
- Type definition — “Does
customrecord_exampleexist, and what is its type-level metadata?” - Field definitions — “Which
custrecord_...fields sit on that type?” - Instances — “What values are on rows of
customrecord_example?”
Field definitions are the usual target when people search for CustomRecordCustomField. Progressive querying and column intent lists are in the column reference and type join note. List/Record targets are a separate property discovery problem (list or record type).
Why “one query for every custom field” fails
- Different families may live on different analytical records.
- Some families may be available in the UI but not exposed to the SuiteScript and REST Query API channel.
- Role permissions can hide entire definition records.
- Joins that work in saved search are not automatically valid SuiteQL joins.
- SDF / SuiteCloud XML can list every field for deployment while SuiteQL still lacks a metadata record for analytics.
If you need a full data dictionary export, plan per family and adapt columns per account (export with SuiteScript).
Illustrative multi-family checklist (not a UNION recipe)
Do not copy this as production SQL. Use it as a research checklist:
For each family in scope:
1. Catalog search by known script ID prefix (custrecord_, custbody_, custcol_, …)
2. Confirm analytical record script ID
3. Confirm columns: id, script id, label, type, owner/parent, inactive-style flag
4. Confirm joins to type or list metadata if required
5. Run a three-column probe with ROWNUM or equivalent bound limit
6. Only then combine extracts in SuiteScript or offline—not via inventing a mega-UNION
A UNION ALL across families is only valid when every branch uses catalog-confirmed identifiers and compatible projected columns. Prefer separate queries per family when schemas differ.
Related but different systems
| System | Good for | Not the same as |
|---|---|---|
| SuiteQL / Records Catalog | Analytical discovery and reporting on exposed metadata | Guaranteed full customisation schema |
| SuiteCloud / SDF XML | Deployment, source control, account promotion | SuiteQL record names and joins |
| SuiteScript record metadata APIs | Runtime form/record introspection in scripts | Always matching SuiteQL analytical IDs |
| Saved search | UI-driven reporting | Drop-in SuiteQL field and join IDs |
For deployment XML versus analytics, see SuiteQL Metadata vs SuiteCloud XML for Custom Records. For import workflow, see SuiteCloud: Import a Custom Record and Its Custom Fields.
Caveats
- Catalog output is account-, feature-, role- and channel-specific.
- Do not treat blog or forum table names as universal contracts.
- Custom-record field metadata does not replace querying instance tables for stored values.
- If a family is missing entirely, follow the diagnosis path in Why CustomRecordCustomField Is Missing From SuiteQL and apply the same logic to other families.