Last reviewed: 10 October 2026. Product details reflect this review date. Availability and behavior can vary by account, role and release.
Editorial ink illustration: Two colleagues place different field cards into a shared record organizer.
A sales order can have one customer reference and several different installation dates. Put both facts at the top of the order, and the second one becomes difficult to explain. Which installation does that single date describe? Put the reference on every line, and someone must keep repeated copies consistent.
Before creating a custom field, decide what one value represents. That small design decision affects entry, imports, searches, approvals, and the people who use the information later. This lesson gives administrators and process owners a practical way to choose between a transaction body field and a transaction column field, then prove that the choice works.
Custom fields can extend NetSuite records and transactions. The available setup, access, and behavior depend on the field category and your account configuration. Treat the exercise below as a design and testing method; have an authorized administrator configure and test it in an approved environment.
A label such as “Reference” leaves too much unsaid. Ask the person requesting the field to finish this sentence: “For each ___, we need to know ___ so that ___.”
For example: “For each sales order, we need to know the customer's delivery reference so that the receiving team can match our delivery paperwork.” That sentence establishes an owner, a level, and a use. A second sentence might be: “For each installation service line, we need to know its agreed appointment date so that scheduling can plan the work.”
Discuss a counterexample before accepting either statement. Can one order cover two delivery references? Can one service line require several appointments? If the answer is yes, a single field may not represent the process. You may need a more detailed record relationship rather than squeezing several values into one text box.
The lesson on NetSuite record and transaction relationships helps when the information belongs to another business object entirely. The goal is to preserve the meaning of the data, even when that requires a different design from the first request.
A transaction body field holds information at the transaction level. A transaction column field holds information at the line level. Ask: if this order has ten lines, should the field still have one answer, or might each line legitimately have a different answer?
For the delivery reference, one answer per order is suitable only if the business really treats it as an order-wide fact. For the installation date, separate line values support separate service appointments. The fields may appear close together on a screen, but their meaning and reporting use differ.
Avoid making this decision from appearance. Moving a field to a convenient part of a form does not change the business level of the fact. Equally, the presence of the same order-wide value beside several rows in a report does not necessarily mean the system stores independent values on those lines.
Record the decision in a sentence that a new colleague can understand: “Customer delivery reference belongs to the order; installation date belongs to each applicable service line.” Keep that sentence with the field definition and training material.
Consider a fictional business, Pinebridge Equipment. Its customer requests two installations under delivery reference DEL-482. The first service is planned for 12 November and the second for 19 November. These dates and the reference are invented training data.
The proposed order contains:
If Pinebridge stores installation date only on the body, it must either choose one date, overwrite one with the other, or type a sentence containing both. Each workaround loses something. A single date hides the second appointment. An overwritten date can mislead the first installer. A text sentence makes date-based sorting and filtering harder to define reliably.
The line-level design allows the team to ask a useful question: which service lines have installations planned for next week? The answer should identify the matching service, order, and date. It should not silently imply that every service on the order shares that date.
Now change the example. Suppose the customer gives different delivery references for the two installations. Pinebridge must revisit its earlier assumption. The body-field choice is no longer justified merely because it was convenient for the first order. Ask whether orders should be separated, whether the reference belongs to lines, or whether a related scheduling structure is needed. That is a process decision before it becomes a setup change.
After deciding the level, choose a supported field type that matches the fact and how people will use it. An appointment date should behave as a date. A quantity should support numerical interpretation. A controlled business category may need an agreed list rather than unrestricted spelling.
Text remains useful for references whose punctuation and leading zeros carry meaning. A reference such as 000482 is an identifier, not a number to add to another identifier. Define a realistic maximum length and acceptable format where appropriate to the configured type.
Ask what downstream users will do with the value. Will they sort it, filter a queue, include it on a document, compare it with another record, or use it in automation? A field that is comfortable during entry can still be awkward during reporting.
Also define empty values. Does a blank installation date mean “not scheduled,” “not applicable,” or “unknown because the data is incomplete”? Those meanings lead to different actions. If the distinction matters, capture it deliberately rather than asking every report reader to guess.
These three ideas answer different questions. A required value establishes that the process expects information before some agreed point. A default supplies an initial answer. A sourced value comes from another configured place. None of them, by itself, establishes that the answer is correct for this transaction.
For Pinebridge, defaulting every installation to today's date would make data entry faster while creating misleading scheduling information. A better design may leave the field empty until an appointment is agreed. Whether and when that field becomes mandatory should follow the actual service process.
For a sourced delivery reference, decide whether the transaction should preserve a historical value or reflect a current value from another record. Ask the administrator to explain the field's storage and sourcing properties and demonstrate the result. Do not assume that all sourced fields update at the same time or that a change to the source rewrites existing transactions.
Write down who can override the value and when. If users, imports, integrations, and workflows can all populate it, define which source should prevail. A predictable rule is more valuable than a field that happens to look correct after manual entry.
Before configuration, agree on the following details:
Give the field helpful explanatory text. “Enter the appointment agreed for this service line” is more useful than repeating “Installation Date.” Include one example and one common exception in the team procedure.
Start with a two-line test order like Pinebridge's. Use the intended business role, enter the values, save, reopen, and check that each value is associated with the correct level. Then change only the second appointment date and verify that the first remains unchanged.
Inspect the relevant search or report. Select a date range that includes one appointment but excludes the other. Check the returned line identity and order reference. This catches a design that appears fine on the form but produces misleading output.
Test the roles that need access and an appropriate restricted role. Hiding a field on one form is not a complete access design. Ask the administrator to verify field access and the other authorized routes through which the value can be seen or changed.
If imports populate the field, run a small approved import with deliberately different line dates and verify the saved result. Use CSV import matching and update principles to define which record and line the input is meant to change. If automation also changes the field, review its timing with the SuiteFlow states and triggers lesson.
If all lines show the same date, first confirm which field the form and report are displaying. You may be looking at a body value repeated in a line-oriented result. Compare the field identifier and configured category before creating another field.
If an imported value disappears, record the value before submission, after saving, and after reopening. Have the administrator investigate sourcing, defaults, workflows, and scripts that could apply at those points. Changing several settings at once makes the explanation harder to establish.
If one user cannot see the field, compare role access, form assignment, and field display configuration. Avoid solving a narrow visibility issue by giving broad administrative access. If reports fail after a field change, review dependent searches and field type or permission changes before blaming the underlying data.
Treat changes to a field with existing data as a separate controlled task. In particular, deletion can remove related data and disrupt dependent reports. An approved replacement needs a data-preservation and dependency plan; renaming a label alone does not move existing values to a new structure.
For teams turning these choices into daily working habits, CuriousRubik's NetSuite training can help connect configuration decisions with realistic entry and reporting exercises. A well-designed custom field earns its place by making the next person's work clearer.