NetSuite Administrator common mistakes
NetSuite Administrator · Understand the traps and how to avoid them.
Treating role permissions as a flat list and assuming that granting a permission on one role gives the user access, instead of checking how multiple roles combine and which restrictions override.
Candidates learn permissions one screen at a time and never internalize that a user with several roles gets the union of permissions, while global restrictions and department/class/location restrictions on individual roles can still block records. They answer based on the single role shown in the scenario.
What to do instead
For every access question, list all roles the user holds, take the union of permissions, then apply each role's restrictions and any global permission settings. Remember that a restricted role cannot see records outside its restriction even if another unrestricted role grants the permission, and that the most permissive grant wins for permission level while restrictions are evaluated per role.
Answering that a user with the Administrator role can be locked out by IP or password rules, or that an administrator can always see all data regardless of restrictions.
The Administrator role is a common shortcut answer, but it is still subject to company-wide authentication settings, and the built-in Administrator role has no restrictions only because none are set on it, not because administrators are exempt from the restriction mechanism. Candidates overgeneralize the role's power.
What to do instead
Separate authentication policy from data access. Authentication controls such as password policy, IP address rules, and two-factor requirements apply to all users including administrators unless the specific setting exempts them. Data access is governed by the role's permissions and restrictions, so an administrator role with restrictions applied can be limited. Read the scenario for which layer is being tested.
Confusing a custom role's permission levels, such as Full, Edit, Create, View, and None, with the separate record-level and field-level controls, and picking Full when the scenario needs Edit or View.
The levels look hierarchical, so candidates assume Full is always the safe choice. They miss that Full includes delete and that some actions require a specific level rather than the highest one, and they forget field-level and record-level restrictions sit on top of the permission level.
What to do instead
Map the required action to the minimum level: View for read-only, Create for adding records, Edit for modifying existing records, Full for deleting. Then check whether a field-level restriction or a role restriction further narrows access. When a scenario says a user must not delete, Edit or Create is the answer, not Full.
Assuming a workflow or SuiteScript deployment runs for every user automatically, without checking the deployment status, the audience, and the trigger context.
Candidates focus on the script or workflow logic and skip the deployment record. They forget that a deployment can be Not Deployed, Scheduled, or Deployed, that the audience can be limited to roles or departments, and that some events fire only in the UI or only in web services.
What to do instead
For any automation question, verify four things: deployment status is Deployed, the audience includes the affected users, the trigger events match the action described, and the execution context (user interface, web services, scheduled, or CSV import) is one where the event fires. If any of these is wrong, the automation will not run for that user or event.
Choosing a client script when the requirement needs server-side logic, or choosing a user event script when the requirement is a button or field change in the form.
Script types have overlapping capabilities, and candidates pick the type they remember rather than matching the trigger to the requirement. They also forget that client scripts cannot reliably enforce data integrity because they can be bypassed by integrations and imports.
What to do instead
Match requirement to trigger: field change, button click, or form validation in the UI points to a client script; record create, edit, or delete enforcement that must apply to all entry points points to a user event script; scheduled bulk processing points to a scheduled or map/reduce script; outbound calls to external systems point to a RESTlet or suitelet. If the rule must hold for imports and web services, it cannot live only in a client script.
Editing a standard record, field, or form directly and expecting the change to be safe, instead of customizing through custom fields, custom forms, and custom segments.
The interface allows editing some standard elements, so candidates assume any visible setting is fair game. They miss that standard fields and forms can be affected by upgrades and that the supported path is to add custom fields and custom forms rather than modify standard ones.
What to do instead
Prefer custom fields, custom forms, custom segments, and custom lists for changes. Use the standard customization tools such as field sourcing, form layout, and preferred form assignment. When a scenario asks for the supported way to extend a standard record, the answer is a custom field or custom form, not an edit to the standard definition.
Assuming a CSV import updates existing records by matching on any field, or that import order does not matter, when the import actually needs an external ID or internal ID to update rather than create duplicates.
Candidates run imports in practice by matching names and assume the same works in the exam scenario. They forget that imports create new records unless the import is configured to update using a unique key, and that dependent records must be imported after their references exist.
What to do instead
Identify the key used to match records: internal ID or external ID for updates, and confirm the import is set to update rather than add. Sequence imports so referenced records such as customers, items, and classes exist before transactions that reference them. When duplicates are a risk, the answer involves external IDs and an update-mode import.
Confusing saved searches, reports, and SuiteAnalytics workbook behavior, such as expecting a saved search to aggregate the way a summary report does or expecting a report to join records the way a saved search can.
The three tools overlap in appearance, so candidates pick the one they use most rather than the one that fits the requirement. They miss that saved searches can join related records and drive reminders and workflows, while reports are formatted output and workbooks are for pivot-style analysis.
What to do instead
Match the requirement to the tool: saved searches for joined record lists, criteria, formulas, and as a source for reminders, workflows, and mass updates; reports for formatted financial and operational output; workbooks for pivoted analysis over large datasets. If the scenario needs a reusable record set that other features consume, the answer is a saved search.
Ignoring integration authentication and governance limits, such as assuming a token-based integration has unlimited calls or that a user's password can be used indefinitely.
Candidates focus on mapping fields and endpoints and skip the operational side. They forget that integrations authenticate through token-based authentication or OAuth rather than stored user passwords, and that SuiteScript and web services usage is subject to governance limits that shape the design.
What to do instead
For integration questions, confirm the authentication method, the role the integration runs under, and the governance budget. Token-based authentication with a dedicated integration role is the supported pattern over embedding user credentials. If a scenario involves high volume, the answer accounts for governance limits through batching, scheduling, or map/reduce rather than assuming unlimited calls.
Answering customization and data questions from memory of a single account configuration instead of checking the account-level settings that change behavior, such as features enabled, accounting preferences, and subsidiary or multi-currency settings.
NetSuite behavior depends heavily on which features are enabled, and candidates generalize from the account they have seen. They miss that enabling a feature changes available fields, forms, and workflows, and that preferences such as accounting and tax settings alter how records behave.
What to do instead
Before answering, identify which features and preferences the scenario implies and whether they are enabled. If a capability is described, check that the enabling feature is on and that related preferences are set. When the scenario is silent, choose the answer that is valid under the described configuration rather than assuming defaults from another account.