The Records Browser defines the schema for all scriptable record types; it is an extremely critical reference tool for every SuiteScript developer. When you need to know how to reference a particular field on a specific record type in your script, the Records Browser is your guide.
You may also notice tabs at the top of the Records Browser for Schema Browser and Connect Browser. These are very similar to the Records Browser, but for different NetSuite APIs.
The Schema Browser provides the schema for the SOAP-based Web Services API, while the Connect Browser provides the schema for the ODBC connector.
You browse the Records Browser first by Record Type, i.e. "Sales Order", "Invoice", "Employee". There is no searching capability within the Records Browser, so all navigation is done manually. Record Types are organized alphabetically, so you first click on the first letter of the record type you are interested in, then select the Record Type itself at the left.
For example, if you wanted to see the schema for the Subisidary record type, you would first click on S at the top, then Subsidiary at the left.
Each schema provides you with an overwhelming amount of information about each record type. It is important to know how to break down all of this information.
At the top of the schema is the name of the Record Type followed by the Internal ID of the record type; this internal ID is the programmatic reference for the record type. The schema is then broken up into several sections:
As stated previously, there is no searching capability built in to the Records Browser. Once you've navigated to the appropriate Record Type, if you don't already know a particular field's Internal ID, the easiest way to find it is to use your browser's Find function (usually
CTRL+F) to locate the field by its name in the UI.
The Required column of the schema indicates whether this field is required to save the record. If this column says
true, then you will need to provide a value for this field when saving any record of this type.
nlapiSubmitField column is a critical piece to understand. This column indicates whether the field is available for inline editing. If
true, then the field can be edited inline. This greatly impacts how this field is handled when trying to use the
record.submitFields functions in your scripts.
When this column is
true, you can safely use the Submit Fields APIs to update this field inline. When it is
false, you can still use these functions to update the field, but what actually happens behind the scenes changes significantly.
false for a particular field, and you utilize one of the Submit Fields APIs on it, the scripting engine behind the scenes will actually do a full load of the record, update the field, and submit the change back to the database. The end result is the same, but because the entire record is loaded and saved, your script will actually use a lot more governance than you might expect and will take longer to execute.
You can read about this in more detail on the Help page titled "Consequences of Using nlapiSubmitField on Non Inline Editable Fields."