NetSuite Custom Record Design Spec Template
Custom records are the quickest way to track things NetSuite does not model out of the box, and the quickest way to create clutter. A one-page spec before you build forces the right questions.
Fill in
NetSuite Custom Record Design Spec Template
Custom Record Design Specification
Project: Tooling Calibration Tracker Record: Tooling Calibration Script ID: customrecord_tool_calibration Author: Maria Chen Date: 2026-10-20
Business purpose
Track calibration due dates and results for gauges and fixtures used on the shop floor so quality can show evidence at audit.
Fields
Name (free-form text, required) Gauge item (list/record: Item) Last calibration date (date) Next due date (date) Result (list: Pass, Fail, Adjusted) Certificate (document)
Relationships
Parent: Item record for the gauge. Optional link to Location for where the gauge is stored.
Access and permissions
Quality Manager: Full. Production Supervisor: View. All other roles: None.
Reporting
Saved search of gauges due in the next 30 days, emailed weekly to the quality manager.
Integration and automation
None in phase 1. Phase 2 may add a scheduled script to email overdue gauges.
Build and test plan
| Task | Owner | Sandbox date | Production date |
|---|---|---|---|
| Create record type and fields | |||
| Set permissions on roles | |||
| Build saved searches | |||
| User acceptance test | |||
| Deploy to production |
Approvals
A starting point for your own change process. Custom record script IDs must start with customrecord and cannot be changed easily after records exist, so agree the naming before building.
Review my NetSuite customization design
Optional: send your spec for a practical review of fields, access and reporting.
Optional. The tool and every export work without this. No spam.
How to use the spec
State the business purpose in one or two sentences, list each field with its type, and name the records it connects to. Then decide who can view and edit it and how it will be reported on. Share the exported document with the business owner before anyone opens the Customization menu. Approving a spec takes minutes and saves a rebuild later.
- Write the purpose before listing fields
- Give each field a type: text, list, date, check box, currency and so on
- Name the parent record, if any
- Decide reporting needs up front
Design choices that matter
Choose between a custom record and a custom field on an existing record first. If the data belongs to one transaction or item, a field is usually enough. A custom record suits many-to-one data such as inspection results, calibration events or approvals. Use custom lists or records for fields with repeating values, and decide early whether child records should be a subtab on the parent. Keep script IDs consistent, because they appear in saved searches and scripts.
Permissions and data volume
Access to custom records is granted per role at levels from None to Full, so list them in the spec rather than discovering the gap in testing. Think about volume too. A record created for every work order operation behaves differently in searches than one created per supplier. Note the expected rows per year so developers can plan for indexing and search filters.
Common mistakes
Teams duplicate existing fields, forget to restrict access, or build a custom record for something the standard Item, Location or Subsidiary records already cover. Another trap is skipping the sandbox. Even a simple record should be built, tested and moved by a SuiteCloud project or customization deployment so you can repeat it.
Frequently Asked Questions
When is a custom field better than a custom record?
When the data describes one existing record and has one value per record, a field is simpler. Use a custom record for repeating or independent data, such as multiple calibration events per gauge.
Can the script ID be changed later?
Script IDs are set when the record type is created and are hard to change once data and scripts reference them. Agree a prefix convention before building and keep it consistent across customizations.
Do I need a sandbox for a small record?
It is strongly recommended. Building in a sandbox lets you test roles, searches and any scripts, then deploy the same definition to production instead of recreating it by hand.
Should the spec list saved searches?
Yes. Listing the searches and who receives them shows how the data will actually be used and often reveals missing fields before they are built.
If you plan customizations alongside AI over your NetSuite data, Netray can review the spec and how it would surface in an ERP assistant.
Related Tools
NetSuite User Access Request Form Template
A fill-in access request form for new, changed or removed NetSuite users, with role, subsidiary, segregation of duties review and approval lines.
NetSuiteNetSuite SuiteScript Deployment Handover Template
A handover document for a SuiteScript customization: what it does, where it is deployed, dependencies, how to roll it back and who supports it.
NetSuiteNetSuite Script and Workflow Inventory Worksheet
An editable inventory of the scripts, workflows and scheduled jobs in your NetSuite account, with owners, schedules, daily run minutes and risk level.
NetSuiteNetSuite BOM Revision Change Request Template
A change request for adding a BOM revision in NetSuite: what changes, effective dates, open work order impact and sign-off.
More NetSuite tools
See all- NetSuite Saved Search Formula Generator
- NetSuite CSV Import Template Guide
- NetSuite Role Permission Matrix Worksheet
- NetSuite Inventory Costing Method Reference
- NetSuite Month End Close Checklist
- NetSuite License Cost Estimator
- NetSuite Sandbox and Release Change Log Worksheet
- NetSuite SuiteQL Transaction Query Generator
- NetSuite Transaction Type Codes Reference