How to Find a Custom Field's List or Record Type With SuiteQL

A List/Record custom field stores a reference. Integrations and SuiteQL data queries need two different facts:

The field’s own script ID (custrecord_..., custbody_..., and similar).
What it points at—a custom list, a standard record type, or another custom-record type.

This note is only about finding that target type from field-definition metadata. It supports How to Query NetSuite Custom Record Fields With SuiteQL and does not replace the full discovery checklist.

Every record name, column name and join below is illustrative. Confirm analytical IDs in Setup → Records Catalog under the SuiteScript and REST Query API channel for the execution role. Metadata record families differ by custom-field family and are not guaranteed in every account.

Definitions versus values

Question	Where to look
Is this field List/Record (or Free-Form Text, Checkbox, …)?	Field-definition metadata (type / datatype column if exposed)
Which list or record type does it reference?	Field-definition metadata (select/record target fields or joins if exposed)
Which internal ID is stored on a particular row?	Instance data on the parent record (`customrecord_...`, transaction, entity, …)

Querying instance values never tells you the configured target type by itself. A stored 123 only makes sense after you know the field points at, for example, a status list or a related custom record.

Start from the correct field family

Custom-record fields, transaction body fields, entity fields and other families are separate metadata surfaces. Do not assume one catalog record describes every family.

Open Records Catalog with the role that will query.
Select the SuiteScript and REST Query API channel.
Search for the field’s script ID (for example custrecord_example_status) via Global Field Search.
Note which analytical record exposes that field’s definition.
On that definition record, list available fields and joins—especially anything that describes field type and select/record target.

For custom-record fields, the definition record is often named like CustomRecordCustomField. For other families, search those families explicitly. See NetSuite Custom Field Metadata Tables Explained.

Illustrative discovery steps for the target

Use this as a workflow, not a fixed schema:

Confirm the field-definition row for your script ID (minimal columns first):

SELECT
    field_definition.id,
    field_definition.scriptid,
    field_definition.label
FROM
    CustomRecordCustomField field_definition
WHERE
    field_definition.scriptid = ?

In the catalog, identify the column that means field type (names vary). Project it only after it is confirmed:

SELECT
    field_definition.id,
    field_definition.scriptid,
    field_definition.label,
    field_definition.fieldtype
FROM
    CustomRecordCustomField field_definition
WHERE
    field_definition.scriptid = ?

fieldtype is illustrative. The catalog may use a different ID and may encode values as internal IDs, codes or joined labels—not necessarily the UI string List/Record.

Search the same definition record for columns or joins that describe the select list, record type or related record target. Common intents (names must come from your catalog):

Intent	What to look for in the catalog
Target is a custom list	Field or join toward list / custom list definition
Target is a standard record	Field storing record-type key or a join to type metadata
Target is a custom-record type	Field or join toward custom-record type definition
Multi-select vs single	Separate type or flag if the catalog exposes one

Only after a target identifier is confirmed, optionally join to type or list metadata to resolve a human-readable name or script ID. Do not invent that join; use joining field definitions to type definitions as a pattern when the catalog documents it.

Illustrative shape once the target column is known

SELECT
    field_definition.id,
    field_definition.scriptid,
    field_definition.label,
    field_definition.fieldtype,
    field_definition.selectrecordtype
FROM
    CustomRecordCustomField field_definition
WHERE
    field_definition.scriptid = ?

selectrecordtype is illustrative. Your account may expose a different field, a join only, or no target column for SuiteQL at all. If the catalog does not list a target relationship for the analytics channel, SuiteQL cannot invent one—use the UI, SDF object XML or another documented API surface for that property.

After you know the target

Data queries still use the field’s own script ID on the parent instance table. The target type tells you how to interpret and join the stored ID.
Join instance data to the target list or record table only with a confirmed SuiteQL join or key—again from the catalog, not from the customisation form alone.
Permissions on the target record affect whether values resolve; definition metadata can succeed while instance lookups fail under a restricted role.

Caveats

Role and channel: Records Catalog and SuiteQL are role- and channel-specific. Re-check under the production execution role.
Unavailable items: Enable Show Unavailable Items when the type or target property is greyed out or missing.
UI labels: “List/Record” in the UI is not a SuiteQL field ID. Map through the catalog’s type encoding.
SDF XML: Object definitions often carry select/record attributes in XML for deployment. That is not the same as SuiteQL metadata. See SuiteQL Metadata vs SuiteCloud XML for Custom Records.
No universal column list: Accounts differ. Treat any blog example as a template until verified locally (column reference habits).