Writing / Netsuite

How to Find SuiteQL Table and Field Names

Use the NetSuite Records Catalog to find SuiteQL record, field and join IDs, understand role-specific availability and diagnose unknown identifier errors.

Finding the right table and field names is often harder than writing the SuiteQL query itself.

NetSuite has several schemas and reference tools. A record or field visible in SuiteScript, saved search, SOAP or the UI is not automatically available under the same name in SuiteQL.

For SuiteQL, start with the Records Catalog.

Open the account-specific schema

Go to Setup → Records Catalog. Access requires the Records Catalog permission on the current role.

Select the SuiteScript and REST Query API channel. Oracle identifies this channel as the reference for constructed N/query queries, SuiteQL through SuiteScript, REST query and Workbook-related analytics data.

The catalog is dynamic. It reflects:

  • The role currently signed in
  • Enabled account features
  • Custom records and fields
  • Records, fields and joins available in the selected channel

This is why a query can work for an Administrator but fail for an integration role.

Search in three ways

Record Type Filtering

Use this when you know the business record, such as customer, transaction or accounting period.

Search by a field’s label or script ID. This is the fastest route when you know custrecord_example_status but do not know which analytical record exposes it.

Show Unavailable Items

Enable this when a record, field, sublist or join appears to be missing. The catalog can then show items that exist but are unavailable in the current context.

Copy IDs, not labels

The display label is for humans. SuiteQL requires the analytical script ID shown by the catalog.

For example, the catalog might show:

Label: Customer
Script ID: customer

and fields such as:

Label: Internal ID
Script ID: id

Label: Customer ID
Script ID: entityid

Use the script IDs in SQL:

SELECT
    customer.id,
    customer.entityid
FROM
    customer
ORDER BY
    customer.id

Confirm joins in the catalog

Do not infer a join from two similar labels. Open the source record and inspect its documented joins, including the target record and cardinality.

Then test a minimal join before adding the rest of the report:

SELECT
    source_record.id,
    joined_record.id
FROM
    source_record
    LEFT JOIN joined_record
        ON source_record.documented_join_field = joined_record.id
WHERE
    ROWNUM <= 10

Replace the illustrative names with the exact record and field IDs shown in your catalog.

Test the smallest useful query

When exploring an unfamiliar record, avoid starting with a large SELECT * query. Choose an ID and one recognisable field:

SELECT
    customer.id,
    customer.entityid
FROM
    customer
WHERE
    ROWNUM <= 10
ORDER BY
    customer.id

Add one field or join at a time. If the query fails, the last addition identifies the likely problem.

Records Browser versus Records Catalog

The older Records Browser remains useful for SuiteScript record APIs and other interfaces, but it is not the authority for the analytics data source.

Use:

  • Records Catalog for SuiteQL, N/query, REST query and Workbook analytics records.
  • Records Browser for SuiteScript record fields, sublists and search-oriented references where applicable.
  • SOAP Schema Browser for SuiteTalk SOAP records.

Using the wrong reference commonly produces a field ID that looks legitimate but is not available in SuiteQL.

Common failure patterns

Unknown identifier or field

Confirm that the value is a script ID rather than a label and that it belongs to the selected record.

Record not found

Check the channel, current role, enabled features and Show Unavailable Items.

Query works for one role only

Compare the Records Catalog under both roles. The analytics schema is permission-aware.

A custom field is missing

Search globally by the full cust... script ID. Confirm that the field is available for the SuiteScript and REST Query API channel, not merely visible on a form.

A saved-search join does not work

Saved Search and SuiteQL are different query systems. Find the analytical join in the Records Catalog instead of copying the saved-search join name.

Keep a local schema note

For complex projects, record the following beside the query:

Record: transaction
Fields: id, tranid, lastmodifieddate
Join: confirmed in Records Catalog
Execution role: integration role
Verified: 2026-07-20

That small note makes future permission and account-configuration changes much easier to diagnose without embedding workplace-specific details in public code.