The Ultimate Guide to NetSuite User Roles, Permissions and Access Management

1. The four-layer access model

Oracle's own guidance for administrators is blunt about the shape of this: give employees only the access they need, do not assign standard roles to users, customize standard roles instead, create roles for each job function, and assign more than one role when someone genuinely does more than one job.

The single most useful sentence in the Oracle documentation on this topic is the one most teams have never read: users with create or full permissions to a restricted record type can create and submit new instances of that record type, but cannot view the records they just created. Users cannot view records they are restricted from, regardless of permission level.

That behavior is correct and intentional, and it is also the explanation for a large share of "I saved it and now it is gone" support tickets. If you see that pattern, the problem is almost never the permission. It is a restriction.

One more structural point for US multi-entity businesses. A single employee can hold several roles and switch between them, which is the right pattern when one person legitimately performs two separable duties. It is also how you preserve segregation of duties without giving one role everything. The wrong pattern is one fat role that covers every hat that person wears.

2. Role types, centers and special roles

Standard vs custom

NetSuite ships a library of standard roles such as Accountant, A/P Clerk, Sales Manager and System Administrator. Standard roles are not editable. To change one you click Customize, which creates an editable copy, and you assign the copy. Oracle's setup checklist states the rule directly: do not assign standard roles to users.

Why it matters practically. When Oracle changes a standard role in a release, your users inherit that change whether or not it suits you. A customized copy gives you a controlled baseline, and it gives your auditors something with a documented owner.

Center types

Every role belongs to a center, which determines the navigation structure the user sees. The center type is chosen when the role is created and cannot be changed after the role is saved, so getting it wrong means rebuilding the role.

Special role settings worth knowing

• Web Services Only Role. Restricts a role to API access, blocking UI login. Correct for integration users, and the cleanest way to stop a service account being used as a human login.
• Single Sign-On Only Role. Forces access through your identity provider. Note that where a role is designated a SAML SSO role, the NetSuite 2FA requirement is ignored, because your IdP is expected to enforce the second factor.
• Restrict by Device ID. Limits a role to specified devices.
• IP address rules. Enforced at company and employee level rather than on the role, and a frequent cause of access failures for remote and travelling US staff.
• Full Access role. Deprecated. Oracle's administrator checklist says plainly: do not use it.

3. Permission categories and access levels

Permissions on a role are organized into subtabs, broadly: Transactions, Reports, Lists, Setup, and Custom Records. Setup is the dangerous one. It holds the permissions that change how the account behaves rather than what is in it.

The five access levels

Oracle documents five general access levels. Each successive level increases what the role can do with the related record type, task or page, although Oracle notes that some permissions do not fit the model exactly, and that for certain permissions only the minimum View level is required for the feature to work, with higher levels adding nothing.

Build up, never down

The most common route to an over-permissioned account is starting from the Administrator role, or a near-admin copy, and removing what the user should not have. It feels faster. It reliably leaves permissions behind, because nobody can hold the full permission set in their head, and the leftovers are invisible until an audit finds them.

Build from the center type upward instead: start from a narrow standard role that matches the job function, customize it, and add only what the user demonstrably needs. Then assign the role to yourself and walk the entire business process end to end before releasing it. Oracle's own checklist includes exactly that step, and it catches the "I can enter the bill but not submit it" class of problem before a user does.

Global Permissions

The Global Permissions feature grants a permission to an employee across every role they hold. Oracle's guidance is to avoid it unless you have to, and to use role permissions and restrictions instead. The reason is auditability. A global permission does not appear where a reviewer looks for it, which is on the role, so it is the single easiest way to hide access from your own access review.

Advanced Employee Permissions

If your account has the Advanced Employee Permissions feature enabled, employee data access is split across permissions such as Employees, Employee Administration, Employee Public and Employee Confidential. This matters for restriction behavior: with that feature on, the restrictions set on the Role page apply only to the Employees and Employee Administration permissions, while Employee Public and Employee Confidential ignore them. US companies handling compensation data in NetSuite should confirm which model their account is using before designing HR-adjacent roles.

4. Restrictions and their edge cases

Restrictions are set on the Restrictions subtab of the role record, and they are where role design gets genuinely subtle. They limit a role's access to transaction, customer, employee, partner and optionally item records based on field values on those records. They can also limit the values a user may assign to those fields.

The three restriction levels

For employee, department, class and location, the levels are consistent:

• none, default to own: no restriction on what can be selected, but the field defaults to the user's own value
• own, subordinate, and unassigned: the user's own value, its children, and records where the field is blank
• own and subordinates only: the user's own value and its children, excluding unassigned records

For subsidiary restrictions the model differs: the role can be limited to the user's own subsidiary, or to a selected set of subsidiaries.

Six edge cases that cause real incidents

1. Unassigned records leak through. With "own, subordinate, and unassigned," any record where the field is blank is visible. If your department field is inconsistently populated, that restriction is doing far less than you think. Oracle notes separately that any Chart of Accounts account without an assigned department is not subject to the own-subordinate-unassigned or own-and-subordinates-only restrictions at all.

2. Restrictions are ignored when the employee record is incomplete. If a custom role does not have a department, class or location set on the user's employee record, restrictions on those fields are ignored. The role looks restricted on screen and behaves unrestricted in practice. This is the failure mode that looks most like a NetSuite bug and almost never is.

3. Expense and time transactions bypass segment restrictions. Class, department, location and subsidiary restrictions are not applied for expense and time transactions. If your control design assumes a location-restricted role cannot see other locations' expense reports, test it.

4. Do Not Restrict Employee Fields is a deliberate hole. Checking this box lets a role with employee restrictions still select any employee in employee fields. It is often necessary, because an employee-restricted user frequently needs to name a colleague on a record or run a report referencing employee fields. It is also an exception to your restriction, so document why it is checked.

5. Allow Cross-Subsidiary Record Viewing does what it says. It lets users see, but not edit, records for subsidiaries their role does not cover. Useful for shared service centers. Also a disclosure decision, not a convenience setting, for US groups with entities that should not see each other's data.

6. Subsidiary restrictions cascade to departments. In OneWorld, subsidiary restrictions automatically apply to departments. A role restricted to Subsidiary X can access only departments assigned to Subsidiary X, even with no department restriction set.

Forms as a fourth control

Restrictions control which records a role reaches. Custom forms control what a role sees on a record. A form can hide fields entirely or mark them read-only, and a role can be restricted to that form. This is how you keep cost prices, vendor payment terms or compensation out of view without blocking access to the record. It is often the right answer when "they need the record but not that field" comes up, and it is cleaner than a second record type. Our NetSuite customization services team builds role-specific forms as a standard part of access design.

5. Administrator vs Core Administration Permissions

The standard Administrator role grants full account access and cannot be customized. It is also 2FA-required by default, permanently.

Core Administration Permissions is the feature that lets you build near-admin access with restrictions applied. It is enabled on all accounts by default, and it can be assigned to any role, which you then configure to restrict access to specific areas of NetSuite. To assign it you must be logged in as Administrator, or with a role that already has Core Administration Permissions plus Manage Roles.

Oracle attaches two warnings to it, both worth repeating. Use caution, because the role becomes similar to the standard Administrator role in terms of exclusive administrative privileges. And when you assign it, you should consider setting the role's Two-Factor Authentication Required dropdown to require 2FA. In practice Core Administration Permissions is itself one of the permissions that forces 2FA on a role, so that consideration is largely made for you.

Where admin access quietly accumulates

• Implementation consultants whose access was never revoked at project close
• A previous partner's team, still active after a transition. We document and tighten exactly this during a takeover, as in our NetSuite partner transition case study
• A developer given admin "temporarily" to debug a script
• Integration credentials created with the Administrator role because it was quicker
• A departed employee's role left active because their records were still referenced

6. 2FA, passkeys and the 2027.1 deadline

This is the section with actual dates attached, and the reason access management is a 2026 priority rather than a 2027 one.

What is already mandatory

NetSuite requires 2FA for all Administrator and other highly privileged roles when logging in to any NetSuite account, including production, sandbox, development and Release Preview. The Administrator role and highly privileged roles are 2FA-required by default and the requirement cannot be removed. This has been enforced across all accounts since 2018.2.

Certain permissions force a role to be 2FA-required. Oracle lists them, and every one of them is a permission a US company should already be treating as privileged:

• Access Token Management (for Token-Based Authentication)
• OAuth 2.0 Authorized Applications Management
• Core Administration Permissions
• Two-Factor Authentication base
• Set Up SAML Single Sign-on, Set Up OpenID Connect (OIDC) Single Sign-on, Set Up OpenID Single Sign-on
• OIDC Provider Setup
• Integration Application

Standard roles carrying the Two-Factor Authentication base permission include Marketing Administrator, Sales Administrator, Support Administrator and System Administrator. You can see which standard and customized roles include these permissions in the Two-Factor Authentication Required column on the Two-Factor Authentication Roles page.

Two consequences teams discover the hard way. All non-UI access through an API, including web services and RESTlets, is also 2FA-required, and 2FA-required roles cannot use user credentials for API authentication. And where a role is designated a SAML SSO role, the 2FA requirement is ignored, because authentication has moved to your identity provider.

What changed in 2026.2

• Passwordless authentication with passkeys. As of 13 July 2026, users can set up a passkey and use it instead of a password to log in.
• Passkey as a 2FA authenticator. In 2026.2 a FIDO2-compliant passkey can serve as the second factor.
• Require 2FA for All Roles. Since 21 September 2026, administrators can require 2FA for all Employee, Vendor and Partner roles. Customer Center, web store and shopper roles are excluded.
• Very Strong Password Policy is available as an account setting. Note that certain highly privileged roles are required to hold at least the Strong policy at all times.

What happens in 2027.1

Alongside it, 2027.1 carries the authentication changes that break integrations rather than logins:

• NLAuth authentication for RESTlets ends, with existing IssueToken integrations excepted
• No new Token-Based Authentication integrations can be created. End of support for TBA is tentatively 2028.2
• PKCE becomes required for new OAuth 2.0 authorization code integrations

We cover the migration path in detail in our TBA to OAuth 2.0 guide, and the wider release context in our NetSuite 2026.2 release breakdown.

The three searches to run before your 2027.1 upgrade

1. Shared and service logins. Any login shared between people, or used by a script or scheduler to sign in to the UI with a password alone, will hit 2FA for the first time. That includes vendor and partner portal logins.
2. Vendor and partner access. These are in scope and are usually the least governed accounts in the system. Confirm every one has a real, reachable person behind it who can complete a 2FA enrollment.
3. Integration authentication. Inventory every NLAuth caller and every TBA integration now. The 2FA change and the integration changes land in the same release.

7. Controlling access to NetSuite AI features

Access management in 2026 includes a question that did not exist two years ago: who can ask the system a question in natural language, and what does the system answer with?

The reassuring part first. Ask Oracle works within your existing roles and permissions, so a user only sees what they are already authorized to see. AI access does not bypass your role design. But it does something your role design was never stress-tested for: it makes data that was technically visible but practically buried instantly retrievable. A role that could, in theory, run a search exposing margin data across every customer now has a conversational interface for doing it.

That is the real governance point. Before enabling AI features, re-examine roles for access that was tolerable only because it was inconvenient to exercise.

What 2026.2 added

• Manage NetSuite Next Access by Role and Manage Ask Oracle Access by Role. Access to both is controlled per role rather than account-wide, so rollout can be staged. NetSuite Next is being made available to customers in phases, which means a feature present in one account can be absent in another on the same version.
• New AI MCP permissions for the Specialized User: CRM role. Administrators can customize that role so users can use the NetSuite AI Connector Service to interact with NetSuite data conversationally. The relevant permissions are Log in using OAuth 2.0 Access Tokens and REST Web Services. Both have a default level of None, and Oracle states administrators should grant them only when needed. The role continues to limit access to the records and actions its existing permissions allow.
• File Cabinet access controls for custom tools. An empty folder list prevents custom tools from reading, creating or updating files, and existing NetSuite role permissions still apply on top.
• AI preference changes for NetSuite AI Units, which affects consumption rather than access, but belongs in the same rollout conversation.

For the connector architecture behind this, see our NetSuite MCP and AI connector guide, and for the platform direction, our NetSuite Next overview.

8. Segregation of duties and SOX

For US public companies and those preparing for an IPO, NetSuite role design is not an IT exercise. It is the control environment that Section 404 of the Sarbanes-Oxley Act requires management to assess and the external auditor to attest to. Private companies carrying SOC 1 or SOC 2 obligations, or bank covenants requiring audited financials, face a similar test.

Segregation of duties means no single role can initiate, approve and conceal the same transaction. In NetSuite terms, these are the conflicts auditors look for first.

Two things auditors ask that catch teams out

"Show me who could do this, not who did." Evidence that no inappropriate transaction occurred is not evidence of a control. The question is whether the access existed. That makes your role records, not your transaction history, the primary evidence.

"How do you know this is still true?" A role design documented at go-live and never reviewed carries little weight three years later. The control is the recurring review, not the original design. Section 10 sets out how to run it.

Compensating controls are legitimate where separation is genuinely impossible, which is common in US companies with small finance teams. A two-person accounting department cannot separate everything. What it can do is document the conflict, implement a detective control such as an independent review of a specific exception search, and evidence that the review happened. An acknowledged conflict with a working compensating control is a defensible position. An unacknowledged one is a deficiency.

We built the approval routing and reporting layer behind this kind of control for a B2B distributor whose sales order approvals needed constant manual intervention. The detail is in our NetSuite approval workflow case study, and the build pattern is covered in our guide to automating workflows with NetSuite.

9. Auditing roles and access in NetSuite

Oracle states that assigned permissions can be audited through searches of role and employee records, and assigned restrictions through searches of role records. That is the mechanism. Here is what to actually build.

The tools

The five saved searches to build once and keep

1. Privileged role holders. Every employee holding a role with Administrator or Core Administration Permissions. Send it to the control owner monthly.
2. Full-level permissions. Every role holding any permission at the Full level, grouped by permission. This is your delete-rights inventory.
3. Active users, inactive employees. Employee records marked inactive or terminated that still have login access or assigned roles. The highest-value search on this list.
4. Roles with no restrictions. Custom roles with transaction permissions and an empty Restrictions subtab, to catch roles that were meant to be scoped and never were.
5. Dormant access. Users with no login in 90 days, cross-referenced against roles held. Dormant privileged access is the cheapest risk to remove.

If saved search formulas are not familiar territory, our NetSuite saved searches guide covers the mechanics. For login and access failures specifically, our write-up of the most common NetSuite support issues walks through the usual causes.

10. The quarterly user access review

A user access review is the control that makes everything above defensible. It needs to be boring, repeatable and evidenced. Here is a cadence that survives an audit without consuming a week.

What the evidence pack needs to contain

• A role catalog: every custom role, its purpose, its business owner, and the standard role it derives from
• A user-to-role matrix as at the review date, exported and retained
• Manager attestation that each person's access matches their current job
• The SoD conflict matrix, with conflicts either resolved or documented with a compensating control
• An exception log showing what was found and when it was remediated
• Proof that terminated users were removed, with dates
• The 2FA-required role list from the Two-Factor Authentication Roles page

Most US mid-market companies fail this not on design but on retention. The review happens, nobody exports anything, and six months later there is no evidence it occurred. Export the search output every time and store it with a date.

If nobody internally owns this, it is a reasonable thing to outsource. Access reviews, permission audits, role-bloat cleanup and audit-ready evidence packs for SOX and SOC 2 are part of our NetSuite administration services, and ongoing governance across both annual releases sits within NetSuite managed services.

11. A role design blueprint

A starting structure for a US mid-market business on OneWorld. Adjust to your authority matrix. The point is the shape: narrow roles, stacked where someone genuinely holds two jobs.

Getting this structure right at implementation is considerably cheaper than retrofitting it. Role design is part of how we scope NetSuite implementation services, and remediating it afterwards is one of the most common reasons companies engage NetSuite Support Services.

12. Twelve mistakes we keep finding

1. Assigning standard roles directly. Oracle's checklist says do not. Release changes to a standard role propagate to your users without review.
2. Starting from Administrator and removing access. It always leaves something behind. Build up from a narrow role instead.
3. Treating Full as "make it work." Full includes delete. Most operational roles need Edit at most.
4. Using Global Permissions for convenience. It applies to every role the employee holds and does not appear on the role record, so it hides access from your own review.
5. Restrictions with inconsistent segment data. A department restriction over a half-populated department field restricts almost nothing.
6. Forgetting that unassigned records leak. "Own, subordinate, and unassigned" includes every blank-field record in the account.
7. Assuming restrictions cover expense and time. Class, department, location and subsidiary restrictions are not applied to those transactions.
8. Never setting the segment on the employee record. Without a department, class or location on the user's employee record, those restrictions are ignored entirely.
9. Running integrations on admin credentials. Use Web Services Only roles with scoped permissions. Also note that 2FA-required roles cannot use user credentials for API authentication.
10. Leaving the Full Access role in play. It is deprecated. Replace it.
11. Not revoking consultant and former-partner access. Including ours, when a project ends. Ask for it in writing.
12. Reviewing access but keeping no evidence. An unevidenced control is, to an auditor, an absent one.

If several of these sound familiar, that is normal. Access drift is not a breach, it is accumulation, and it is invisible until an audit or an incident surfaces it. A structured NetSuite health check is the usual way to find out where you actually stand, and our NetSuite administrator fundamentals guide covers the surrounding admin discipline.

Frequently asked questions

Product behavior described here is drawn from the Oracle NetSuite Help Center, including Access Levels for Permissions, Permissions and Restrictions, Setting Employee Restrictions, Setting Department, Class, and Location Restrictions, Core Administration Permissions, Mandatory Two-Factor Authentication for NetSuite Access, Permissions Requiring Two-Factor Authentication, and the NetSuite 2026.2 release notes for Account Setup and Maintenance, Authentication and CRM. Release dates and behavior are Oracle's published plans and can change. Verify against your own account before relying on any detail for a compliance or go-live decision.