SuiteCloud Customization and Custom Objects
This domain tests custom object design: choosing the correct object type, applying the ID conventions NetSuite enforces, and understanding how records, fields, segments, and forms interact with roles and reporting.
IDs are permanent
Script IDs are assigned at creation and cannot be changed afterwards - only labels can. Learn the prefixes: custbody_ transaction body, custcol_ line/column, custentity_ entity, custitem_ item, custrecord_ field on a custom record, custlist_ custom list, custform_ custom form, custscript_ script parameter, custevent_ event. Custom record types use customrecord_, and custom segments use cseg_.
Records, fields, segments
Custom record types carry their own permissions by role, plus options such as attachments, system notes, and parent-child hierarchy. Custom fields can apply to several record types, store a value or source it from another field, and define validation and defaulting. Custom segments are the classification tool: they are surfaced across transaction types, can be attached to GL-impacting lines, and support hierarchical values and reporting filters - something a plain custbody_ field does not provide.
Worked example. A business wants a "Project Phase" classification visible on every transaction type and usable to filter GL reporting. Reasoning: a custbody_ field would need recreating per record type and would not behave as a classification dimension. Build a custom segment (cseg_) whose values come from a custom list or custom record, apply it to the relevant transaction types, and set its GL impact and display options. Field-level defaults then propagate to lines.
Traps
- Using
custbody_for data that varies per line - that needscustcol_. - Expecting to rename a script ID after records already reference it.
- Confusing custom record permissions with role permissions; both must allow access.
- Building a custom record when the requirement is GL classification across transactions, where a segment is correct.