NetSuite SuiteFoundation common mistakes
NetSuite SuiteFoundation · Understand the traps and how to avoid them.
Assuming a role's permissions are the only thing controlling what a user sees, and ignoring that subsidiary restrictions, department/class/location restrictions, and the user's assigned subsidiary also gate record visibility.
Candidates study the permissions tree in isolation and treat access as a single-variable problem, so they pick the 'most permissive' answer or overlook restriction dimensions that override a granted permission.
What to do instead
For any access question, enumerate all four gatekeepers: role permissions, subsidiary restrictions on the role, user-level restrictions, and record-level restrictions (department/class/location). Practice tracing a single record from role to visibility.
Confusing role-level settings with company-level preferences, e.g., assuming 'Show Internal IDs' or date-format behavior is set per user or per role when it is actually a company-wide preference (or vice versa).
The Setup menus (Company vs. Users/Roles vs. Personal Preferences) look similar, and candidates memorize the label without the scope.
What to do instead
Build a scope map: for each commonly tested preference, write whether it is Company-wide, Role-level, or User-level. Internal IDs, for example, are enabled at the company level under General Preferences.
Treating 'Customization' as one menu and mislabeling where a change lives - e.g., saying a custom field is created under Setup when it is under Customization > Lists, Records, & Fields, or confusing a custom segment with a custom record.
The Customization menu contains many similarly named submenus, and candidates learn the concept without the navigation path.
What to do instead
Drill the three-level paths for the high-frequency objects: custom fields, custom records, custom segments, custom forms, and custom roles. Practice the 'where would I click' question separately from the 'what does it do' question.
Assuming deleting or inactivating a custom field, custom record, or list value is reversible and safe, and choosing 'delete' as the fix for a misconfigured object.
Candidates transfer general software intuition (delete is fine) into NetSuite, where deletion can fail or be blocked when the object is in use, and inactivation preserves history while deletion does not.
What to do instead
Default to 'inactivate' for list values and records that may have transaction history; reserve 'delete' for unused objects. Memorize that fields in use cannot simply be deleted and that inactivation is the standard decommissioning path.
Mixing up transaction form behavior - e.g., confusing which fields are sourced from the customer/vendor record, which are driven by the item, and which are driven by accounting preferences - and answering as if all fields are manually entered.
Transaction forms are dense and candidates focus on layout rather than the sourcing hierarchy behind each field.
What to do instead
For each major transaction (sales order, invoice, bill, journal), map the source of the key fields: customer record, item record, subsidiary, accounting preference, and form default. Trace one field end-to-end rather than memorizing the form.
Conflating the order-to-cash and procure-to-pay lifecycles - e.g., stating that a sales order posts to the GL, or that a purchase order creates a payable - and misplacing which document is the posting event.
Candidates memorize document names but not which documents are non-posting vs. posting, so they assume every document in the chain hits the ledger.
What to do instead
Build a two-column table for each lifecycle: 'non-posting' (order, fulfillment, receipt, bill creation) vs. 'posting' (invoice, bill, credit memo, vendor credit, payment). Anchor every GL question to whether the document is a posting transaction.
Assuming inventory and item behavior is uniform across item types - e.g., treating a non-inventory or service item like an inventory item for costing, or expecting an assembly to behave like a standalone item.
Item types share a form layout, so candidates assume shared behavior and miss the type-specific accounting and costing rules.
What to do instead
Create a comparison grid of item types (inventory, non-inventory, service, kit/group, assembly, discount) across dimensions: tracks quantity, affects costing, posts to COGS, and supports fulfillment. Answer item questions by first identifying the type.
Confusing saved search components - treating criteria, results, and filters as interchangeable, or assuming a saved search and a report are the same object with the same capabilities.
The saved search builder and the report builder look similar, and candidates learn 'search finds records' without distinguishing the execution model (criteria vs. results vs. runtime filters) or the reporting layer.
What to do instead
Memorize the roles: criteria = which records, results = which columns, filters = runtime user input, highlighting = conditional formatting. Then map when to use a saved search vs. a report vs. a dashboard portlet.
Ignoring CRM record relationships - e.g., treating leads, prospects, and customers as unrelated record types, or assuming converting a lead creates a new customer record rather than updating the existing one.
The CRM menus list these as separate items, so candidates assume separate tables and miss the shared customer record with a status field.
What to do instead
Learn the single customer record model: lead → prospect → customer is a status progression on one record, and conversion updates the record rather than duplicating it. Trace a lead through conversion to opportunity to sales order.
Answering navigation questions from memory of labels rather than the actual menu hierarchy - e.g., guessing whether a feature lives under Setup > Company, Setup > Accounting, or Customization, and picking a plausible-sounding but wrong path.
SuiteFoundation tests breadth of navigation, and candidates under-practice the paths because they focus on concepts, then fall back on plausible-sounding menu names.
What to do instead
Practice the 'find it' drill: for 30 high-frequency features (accounting preferences, tax, currencies, roles, custom fields, saved searches, dashboards), write the exact menu path. Re-drill weekly until the paths are automatic.