# How to Create a Custom Record Type in NetSuite

> Source: https://netray.co/erp-help/netsuite-how-to-create-custom-record-types
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: ERP Help

## Short answer

Go to Customization > Lists, Records, & Fields > Record Types > New, name the record, set the script ID and access type, add custom fields on the Fields subtab, and decide who can see it on the Permissions subtab. Use a custom record when you need a new table of data with its own fields, forms and searches, not just a drop-down list.

## Kind

how-to

## System

netsuite

## Erp

Oracle NetSuite

## Module

Customization / Custom Records

## Query

how to create a custom record in NetSuite

## Alternate Queries

- NetSuite custom record type setup
- NetSuite custom record parent child sublist
- NetSuite customrecord script id
- NetSuite custom record vs custom segment

## Applies To

NetSuite (all editions with SuiteBuilder / Custom Records enabled), SuiteScript 1.0 and 2.x, SDF customrecordtype objects

## Steps

### Create and configure a custom record type

**Items:**

Go to Customization > Lists, Records, & Fields > Record Types > New. Enter Name; the ID defaults to _name and the full script ID becomes customrecord_name. Set the ID deliberately now, because it is what scripts and SDF reference.

Choose Access Type: Require Custom Record Entries Permission (recommended), Use Permission List, or No Permission Required. Most production records should use the entries permission so roles are granted per record type.

Tick the options you need: Include Name Field, Allow Quick Add, Show ID, Allow Attachments, Allow Inline Editing, Include in Global Search, Enable Mail Merge, and Show in List.

Save, then open the Fields subtab and add custom fields (free-form text, list/record, currency, checkbox, date). A list/record field pointing at Customer, Item or another custom record is how you build relationships.

For a parent-child structure, create a field on the child record of type List/Record that points to the parent type and tick Record Is Parent on the child field. The child then appears as a sublist on the parent form.

On the Permissions subtab, grant each role a level (View, Create, Edit, Full). On the Forms subtab, customize the entry form and set the preferred form.

Create a record entry from the list under Lists > Custom or the menu you assigned, then build a saved search of type Custom Record to report on it.

## Sections

### When a custom record is the right tool

**Body:**

A custom record is a full database table inside NetSuite. It gets its own internal ID, forms, list view, search type, workflows, scripts and REST/SOAP/SuiteQL exposure. Use it when you must store structured data NetSuite has no home for: equipment registers, calibration logs, supplier audits, customer-specific pricing agreements, or integration staging rows.

If all you need is a pick list, a Custom List is lighter. If the value should classify transactions and appear in reporting like Department or Class, a Custom Segment is usually better, since it can be added to transaction lines and GL impact. Reach for a custom record when the thing has its own fields and a lifecycle.

### Parent-child records and sublists

**Body:**

NetSuite models a one-to-many relationship through the child record's parent field. On the child custom record, add a List/Record field pointing at the parent type and check Record Is Parent. The parent form gets a sublist of children, and deleting the parent can cascade depending on the Allow Child Record Editing and delete options you chose.

Be careful with the field's Sublist Tab setting and with permissions. A user needs permission on both the parent and the child type, or the sublist renders empty and people assume the data is missing. In SuiteScript 2.x you reach children with search.create({ type: 'customrecord_child', filters: [['custrecord_parent', 'anyof', parentId]] }).

**Code:**

// SuiteScript 2.x: create a custom record entry
record.create({ type: 'customrecord_equipment', isDynamic: true })
  .setValue({ fieldId: 'name', value: 'CNC-04' })
  .setValue({ fieldId: 'custrecord_eq_location', value: 3 })
  .save();

-- SuiteQL against a custom record table
SELECT id, name, custrecord_eq_location
FROM customrecord_equipment
WHERE isinactive = 'F'

### Deploying and changing custom records safely

**Body:**

Script IDs cannot be changed freely once records, fields or scripts reference them, so treat them as an API. Keep a naming convention (customrecord_ then a functional prefix) and keep field IDs consistent (custrecord_ prefix). Avoid renaming types in production; add a new field and migrate data instead.

For anything beyond a single account, manage the type as an SDF customrecordtype object in a SuiteCloud project and deploy it from sandbox to production rather than rebuilding by hand. Fields, forms and permissions travel with the object, which prevents the common drift where production is missing a field the script expects.

## Pitfalls

- Leaving the default script ID: scripts and SDF then depend on a name someone later wants to change, and IDs are painful to alter after data exists.
- Using No Permission Required, which exposes the record to every role that can reach the URL or a saved search.
- Forgetting to grant the custom record permission to integration roles, so a RESTlet or SuiteTalk call returns a permission error while the UI works for admins.
- Building a custom record for a simple drop-down. A Custom List or Custom Segment is cheaper to maintain.
- Adding hundreds of fields to one type, which slows forms and searches. Split into related records.

## Ai Angle

An AI assistant grounded in NetSuite can read the list of custom record types and fields, then answer questions such as which records reference a given customer or which roles lack permission on a type. ERPray shows the SuiteQL it ran against the customrecord table and respects role permissions, so it only returns rows that user may see. Designing the data model and permissions remains a human decision.

## Faq

### Can I change a custom record's script ID later?

**Answer:** Technically you can edit it in some cases, but anything referencing the old ID (SuiteScript, saved searches in formulas, SDF files, integrations) breaks. Decide the ID at creation and treat it like a public API name. If you must rename, create a new type or field and migrate the data with a CSV import.

### What is the difference between a custom record and a custom segment?

**Answer:** A custom segment classifies transactions and lines like Department or Class and flows into financial reporting. A custom record is a standalone table with its own fields and lifecycle. Use a segment for classification across transactions and a record for data that is its own entity.

### How do I report on a custom record?

**Answer:** Create a saved search with the type Custom Record and choose your record type. You can join to related records through list/record fields. For SQL style access, SuiteQL exposes the table under its script ID, for example customrecord_equipment.

### Why can't a user see the child sublist on the parent form?

**Answer:** Usually permissions. The role needs at least View on the child custom record type as well as the parent. Also check that the child's parent field has Record Is Parent set and that the form the user opens includes the sublist tab.

## Search terms

netsuite custom record, create custom record type netsuite, netsuite customrecord script id, netsuite custom record parent child, netsuite custom record permissions, netsuite custom record saved search, netsuite custom record vs custom segment, netsuite sdf customrecordtype, netsuite suitebuilder

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json