NetSuite custom fields are incredibly powerful and flexible, but they are not easy to work with! Below is a quick guide that walks through how to create customer and transaction custom fields and some tips and tricks for working with custom fields.

How to create a custom customer (i.e. entity) field in NetSuite:

1. Navigate to: Customization > Lists, Records & Fields > Entity Fields > New
2. Label: use a name you’d like to see displayed on your customer.
3. Type: “Free-form Text”. There are cases where you won’t want to use free-form text, but in most cases this is the best option.
4. ID: “_a_internal_identifier”. Note that you should start your identifier with a _ since custentity will be prepended to whatever you provide here. You’ll want to change “_a_internal_identifier” to an ID that is descriptive of this field in your setup.
5. Store value: checked
6. Applies to: Customer
7. Save

How to create a transaction (invoice, cash sale, order, payment, etc) field in NetSuite:

1. Navigate to: Customization > Transaction Body Fields > New
2. Label: use a name you’d like to see displayed on your transaction.
3. ID: _a_internal_identifier. Note that you should start your identifier with a _ since custbody will be prepended to whatever you provide here.
4. Type: free form text
5. Store Value: checked
6. Applies to: Sale, Payment, etc. Where you want this field displayed is up to your use-case.
7. Global Search: checked. This enables you to search for the value in the NetSuite global search
8. Save

Other Tips & Tricks for Working With NetSuite Custom Fields

• Customer (entity) custom fields will always start with custentity. Transaction (invoice, sales order, payment, etc) custom fields will always start with custbody.
• You can create custom fields on most, but not all records. For instance, you can’t create a custom field on the currency record in NetSuite but you can create one on a subsidiary.
• It’s possible to access “hidden” fields that are not available through SuiteTalk or SuiteScript using field defaults or formula field defaults on custom fields.
• You can source values from a related record. For instance, if you want to source a value from a CashSale connected to a CashRefund you could use a formula like {createdfrom.externalid} as the default value for a field that doesn’t store a value.
• A field which does not store value (i.e. a field that just contains a default value) is not available via a formula on another field. A field not found error will be reported. In other words, you can’t nest formulas. This is a huge bummer.
• If “formula” is not checked when creating the custom field you can still substitute field values using the {field} syntax
• You’ll get ERROR: Invalid Expression for lots of different types of errors. For instance, if your formula doesn’t output the correct field type you’ll get this error. This makes it very challenging to debug why a formula isn’t working.
• Join fields (i.e. {entity.datecreated}) strips the value of its type. Everything comes over as a string.
• You can use SQL functions in a formula field default