NetSuite Setup, Customization, and Administration
Setup work falls into a few buckets: company setup (subsidiaries, currencies, tax, accounting preferences), user and role management, customization (custom fields, forms, records, segments), and features enabled under Enable Features. Feature enablement is largely one-way-once enabled, many features cannot be disabled-so questions often test whether you know that enabling a feature changes available fields and behavior across the account.
Customization questions center on the custom field model: a field has a type (text, list/record, date, currency), an applied-to record, and display options (mandatory, store value, show in list). The trap is store value-it saves the value to the database rather than computing it on the fly, which matters for reporting and performance. Custom segments (custom segments and custom lists) extend the chart of accounts and transaction lines. Custom forms control layout and which fields are visible, but a form cannot grant access the role does not have.
Role and permission traps are frequent. Permissions are grouped by type (transactions, lists, setup, reports) and have levels (none, view, create, edit, full). A role with view-only access to a record cannot edit it even if the form shows the field. Subsidiary restrictions on a role limit which subsidiaries a user can transact in. Two-factor authentication and password policies are account-level settings, not role-level.
Worked example: a user reports a custom field is missing on a form. Check in order: (1) is the field applied to that record type, (2) is it added to the form the role uses, (3) does the role have permission to see that field's source record, (4) is it hidden by display type. Rule of thumb: permission beats form, form beats field default.