What are the permission levels in NetSuite?

NetSuite defines five access levels for permissions. None means the user has no access to that permission. View allows the user to see and print records but not create, edit, or delete them. Create allows the user to create new records and view existing ones but not edit records already created. Edit allows the user to create, view, and edit records but not delete them. Full allows the user to create, view, edit, and delete records. Each successive level adds capabilities to the one below it. For most operational roles, View or Edit is the appropriate ceiling, and Full should be reserved for roles that specifically require deletion rights. Lightbridge ERP applies the principle of least privilege by starting role designs at the lowest level that supports the job function.

What are the permission types in NetSuite?

NetSuite organizes permissions into five categories. Transactions govern access to financial documents such as invoices, bills, journal entries, purchase orders, and sales orders, including approval capabilities. Reports determine what financial and operational reports a role can run. Lists cover non-transactional master records such as customers, vendors, employees, and items. Setup grants access to administrative configuration tasks including accounting preferences, workflow management, and user management. Custom Records apply to records created by SuiteApps and custom development, with each custom record type carrying its own permission. Setup permissions carry the highest risk because they control system configuration, so Lightbridge ERP scopes them to administrator and IT roles and treats them as their own access review category.

What is the difference between standard and custom roles in NetSuite?

Standard roles are predefined by NetSuite and come with fixed permission sets designed to match common employee positions such as Accountant, Sales Rep, A/P Clerk, and Administrator. Standard roles cannot be modified, which means they serve as stable templates. Custom roles are copies of standard roles, or roles built from scratch, that an administrator tailors to the organization's actual structure. A custom role can have permissions added, reduced, or restricted to specific segments, and updating the custom role applies the change to every user assigned to it without touching individual user records. NetSuite recommends starting with a standard role as the template before customizing, rather than building a role from a blank permission list. Lightbridge ERP designs custom roles to match approval hierarchies, department boundaries, and audit requirements rather than copying standard roles unchanged.

What are role restrictions in NetSuite and how do subsidiary, department, and class restrictions work?

Role restrictions narrow the scope of a role's permissions to data matching a specific segment. Subsidiary restrictions limit the records a user can see to those belonging to designated subsidiaries, which is essential in OneWorld accounts where data across legal entities must be segregated. Department, class, and location restrictions filter records by the corresponding segment set on the user's employee record, so a department manager who has Edit access to transactions only sees transactions tagged to their department. Restrictions are configured on the role itself, not on individual users, so every user assigned the role inherits the same scope. When the Subsidiary restriction is set to Selected rather than All, an administrator must update the list whenever a new subsidiary is added. Lightbridge ERP designs restrictions alongside permissions so the scope of access matches the organizational structure from day one.

How does the principle of least privilege apply to NetSuite roles?

The principle of least privilege holds that each user should receive only the minimum access needed to perform their job function. In NetSuite, applying least privilege means starting role permission levels at View or Create rather than Edit or Full, scoping transactional permissions to the record types the role actually touches, using role restrictions to limit subsidiary or department scope where applicable, and never assigning Setup permissions to operational roles. It also means reviewing roles periodically to remove permissions that accumulated through incremental requests. Incorrectly over-permissioned roles introduce financial reporting risk: a user who can create AND approve a transaction, for example, can override the separation of duties that approval workflows are designed to enforce. Lightbridge ERP builds NetSuite role designs from a least-privilege baseline and documents the rationale for each permission granted.

How does NetSuite support segregation of duties through roles and permissions?

Segregation of duties is the principle that no single person should control an entire transaction cycle from initiation to approval and payment. NetSuite enforces it through role design: the person who creates a vendor record should not hold the permission to approve vendor payments; the person who records a journal entry should not hold the Journal Approval permission at a level that allows self-approval. Roles make this separation concrete because permissions are role-bound, and an administrator can verify segregation by comparing role permission sets. Common NetSuite SOD separation points include vendor management versus bill approval, purchase order creation versus purchase order approval, and journal entry creation versus journal entry approval. For how journal entry approval specifically enforces this separation, the Lightbridge ERP guide to journal entry approval covers the native preference and workflow options. Lightbridge ERP maps the organization's approval hierarchy to roles before configuring the system so the separation holds in practice.

How does NetSuite track role and permission changes through the audit trail?

NetSuite maintains two primary audit mechanisms relevant to roles and permissions. System Notes on each record capture every change to that record: who made the change, what changed, and when, and they also record which role the user was logged in under at the time. This means that if a permission was used to create or modify a record, the audit trail traces back to both the user and the active role. The Login Audit Trail records each login event, the role used to log in, and the session details, making it possible to identify roles that are assigned but rarely or never used, which is a common cleanup indicator. Both features are readable by administrators without additional configuration. Lightbridge ERP reviews System Notes and the Login Audit Trail as part of a NetSuite administration engagement to surface unused roles, over-permissioned active roles, and access patterns that deviate from the designed control model.

GP Written by Glenn Paulraj with Robert LabardeeNetSuite Practice Lead and Founder and CEO

Last updated July 2026.

What are NetSuite roles and permissions?

Lightbridge ERP defines NetSuite roles and permissions as the access control system that governs what each user can see and do inside a NetSuite account. A role bundles a set of permissions and restrictions, and assigning a role to a user is the primary mechanism for enforcing least privilege and segregation of duties across every transaction type, report, and configuration task.

NetSuite access control review Talk to an ERP advisor

NetSuite roles and permissions are designed access controls, not defaults to leave untouched.

Every NetSuite user has at least one role, and every role is a collection of permissions that defines what pages the user can open, what records they can create or edit, and what tasks they can complete. The permission model is intentional: NetSuite ships with a library of standard roles, and administrators build from those to create custom roles that match the organization's actual approval hierarchies and data boundaries.

Access control design matters because over-permissioned roles create audit risk. A user who can create and approve their own transactions bypasses the segregation of duties that access controls are built to enforce. A user with Setup permissions for a configuration task they do not perform is a standing risk to system integrity. Lightbridge ERP treats role design as a control discipline, not a one-time configuration task.

Lightbridge ERP is an independent, vendor-neutral ERP advisory firm that delivers NetSuite in-house. It accepts no vendor kickbacks, no reseller quotas, and no partner-tier incentives, so its platform advice is driven by fit rather than commission. This guide is general information, not accounting, tax, or legal advice.

NetSuite permission levels run from None to Full, and each level adds one right to the one below it.

Every permission in a NetSuite role is set to one of five access levels. The levels are cumulative: each adds the rights of the one below it plus one more. Selecting the right level for each permission is the core of least-privilege role design, because the default for many implementations is to assign more than the job function requires.

None

The user has no access to that permission. The page, record, or task is invisible to the role. Applying None deliberately, rather than simply omitting the permission, makes the access model explicit and reviewable.

View

The user can see and print records of that type but cannot create, edit, or delete them. View is the minimum access level required to read data without any modification rights. Users with at least View access can print records of the permitted type.

Create

The user can create new records and view existing ones but cannot edit records already created. This level is useful for data-entry roles where modification of prior work should be restricted to a separate reviewer.

Edit

The user can create new records, view existing ones, and edit existing records. Delete rights are withheld. Edit is the practical working level for most operational roles and corresponds to the largest share of day-to-day access needs.

Full

The user can create, view, edit, and delete records of that type. Full grants deletion rights and should be reserved for roles that specifically require them, such as administrators. Operational roles rarely need Full-level access on transactional permissions.

NetSuite organizes permissions into five types: Transactions, Reports, Lists, Setup, and Custom Records.

Permissions are grouped by the kind of data or action they govern. Understanding which type a permission falls into helps identify where segregation of duties boundaries should sit and which types carry the most audit risk. Setup permissions, in particular, control system configuration and should receive the most scrutiny during any role design review.

Transactions

Controls access to transaction records: invoices, bills, journal entries, purchase orders, sales orders, and similar financial documents. This type also includes approval capabilities for transaction records.

Reports

Determines what financial and operational reports a role can run. Financial statements, saved searches with summary data, and dashboards with financial metrics are governed here.

Lists

Covers non-transactional master records: customers, vendors, employees, items, and price levels. A role that can edit a transaction but only view vendor records is a common separation point.

Setup

Grants access to administrative configuration, including accounting preferences, workflow management, custom fields, and user management. Setup permissions represent the highest-risk category and belong only in administrator or IT roles.

Custom Records

Applies to records created by SuiteApps and custom development. Each custom record type carries its own permission, separate from the four standard types, so custom extensions require their own access review.

NetSuite standard roles are fixed templates; custom roles are where the actual access control design happens.

NetSuite ships with a large set of standard roles matched to common job functions: Accountant, A/P Clerk, A/R Clerk, Sales Rep, Purchasing Manager, and others. Standard roles cannot be modified, which gives them a stable reference point. Their purpose is to serve as a starting template for custom role design.

Custom roles are copies of standard roles, or roles built from a blank template, that an administrator adjusts to match the actual structure of the organization. Adding a permission, reducing an access level, or attaching a restriction to a custom role applies the change immediately to every user assigned to that role, without touching user records individually. This makes role-level management far easier to maintain than per-user permission grants.

One exception to note: Retail Clerk roles cannot be customized due to their limited-access design. For everything else, the recommended approach is to copy the closest standard role, strip permissions that exceed the job function, and document the rationale for every permission that remains. Lightbridge ERP applies this method under change control so the role design is auditable from the start. For the foundational structure of a NetSuite account, see the guide to what NetSuite is.

NetSuite role restrictions scope access by subsidiary, department, class, and location without changing permissions.

A permission defines what a user can do with a record type. A restriction narrows which records they can apply that permission to. The two work together: a role might grant Edit access to transactions, but a subsidiary restriction means the user can only edit transactions in the subsidiaries the role authorizes.

Subsidiary restrictions are especially important in OneWorld accounts where data from multiple legal entities lives in the same environment. Setting subsidiary access to Selected rather than All is a common design choice that enforces entity-level data separation. When new subsidiaries are added to the account, an administrator must update every role where the restriction is set to Selected, so this configuration requires ongoing maintenance. For a detailed treatment of how OneWorld handles multi-subsidiary data, see the guide to NetSuite OneWorld.

Department and class restrictions filter records by the segment set on the user's own employee record. A department manager with Edit access to transactions and a department restriction in place sees only transactions tagged to their department. Location restrictions work the same way. Lightbridge ERP maps these restrictions to the organizational hierarchy during the role design phase so that the data boundaries are built into the role rather than relying on user discipline to avoid out-of-scope records.

NetSuite global permissions override role-based permissions and complicate access audits.

Global permissions is an optional NetSuite feature that allows an administrator to assign permissions directly on an employee record. When active, those permissions apply to the user across every role they hold in the account, and they take precedence over role-based permissions when a conflict exists.

The risk is auditability. Reviewing a user's effective access requires checking both their assigned roles and any global permissions on their employee record. This two-source model is harder to review consistently than a single role assignment. Oracle's documentation and experienced NetSuite administrators generally recommend against relying on global permissions for regular access management. Lightbridge ERP treats global permissions as a last resort for short-term temporary needs and removes them as part of a post-engagement cleanup. Standard access belongs in roles.

Lightbridge ERP designs NetSuite roles from a least-privilege baseline to enforce segregation of duties.

The principle of least privilege holds that each user receives only the minimum access needed to perform their job function. In a NetSuite role design, this means starting permission levels at View or Create rather than assuming Edit, scoping Setup permissions to administrator and IT roles only, applying subsidiary or department restrictions wherever data segregation is required, and periodically reviewing role assignments to remove permissions that accumulated through incremental requests.

Segregation of duties follows from least privilege. When each role holds only what its job function requires, the boundaries between roles naturally separate incompatible functions. The most common NetSuite SOD separation points include: vendor record creation from bill approval, purchase order creation from purchase order approval, and journal entry creation from journal entry approval. For the journal entry approval side of that separation in detail, see the Lightbridge ERP guide to NetSuite journal entry approval.

Lightbridge ERP documents the access model alongside the role design so that an auditor reviewing the configuration sees the rationale for each permission level, not just the current state. A structured NetSuite administration engagement is the right starting point when roles have drifted from the original design and need to be realigned.

NetSuite System Notes and the Login Audit Trail give administrators a complete access history for every user and role.

System Notes are attached to every record in NetSuite and capture each change to that record: who made the change, what field changed, the before and after values, and the date and time of the change. Critically, System Notes also record which role the user was operating under at the time of the change. This means that a permission used to create or modify a record is traceable back to both the user and the role, which is the evidence an auditor needs to verify that a change was made by someone with authorized access.

The Login Audit Trail records each login event with the user, the role used to log in, and session details. Reviewing the Login Audit Trail surfaces roles that are assigned but never actively used, which is a common indicator that the role list needs cleanup. Both audit features are available to administrators without additional configuration. Lightbridge ERP reviews System Notes and the Login Audit Trail as part of a NetSuite administration engagement to identify over-permissioned active roles, dormant role assignments, and access patterns that deviate from the designed control model.

NetSuite roles and permissions: frequently asked questions

What are NetSuite roles and permissions?: NetSuite roles and permissions are the access control system that governs what each user can see and do in a NetSuite account. A role is a named container of permissions and restrictions that is assigned to a user. Permissions define what record types, reports, transactions, and configuration tasks the user can access, and each permission is set to one of five access levels: None, View, Create, Edit, or Full. Restrictions narrow the scope of those permissions to specific subsidiaries, departments, classes, or locations. NetSuite provides a library of standard roles, such as Accountant and Sales Rep, that match common employee functions, and administrators can copy those roles to build custom roles tailored to an organization's structure. Lightbridge ERP designs roles as a deliberate access control layer, not a default setting left in place.
What are the permission levels in NetSuite?: NetSuite defines five access levels for permissions. None means the user has no access to that permission. View allows the user to see and print records but not create, edit, or delete them. Create allows the user to create new records and view existing ones but not edit records already created. Edit allows the user to create, view, and edit records but not delete them. Full allows the user to create, view, edit, and delete records. Each successive level adds capabilities to the one below it. For most operational roles, View or Edit is the appropriate ceiling, and Full should be reserved for roles that specifically require deletion rights. Lightbridge ERP applies the principle of least privilege by starting role designs at the lowest level that supports the job function.
What are the permission types in NetSuite?: NetSuite organizes permissions into five categories. Transactions govern access to financial documents such as invoices, bills, journal entries, purchase orders, and sales orders, including approval capabilities. Reports determine what financial and operational reports a role can run. Lists cover non-transactional master records such as customers, vendors, employees, and items. Setup grants access to administrative configuration tasks including accounting preferences, workflow management, and user management. Custom Records apply to records created by SuiteApps and custom development, with each custom record type carrying its own permission. Setup permissions carry the highest risk because they control system configuration, so Lightbridge ERP scopes them to administrator and IT roles and treats them as their own access review category.
What is the difference between standard and custom roles in NetSuite?: Standard roles are predefined by NetSuite and come with fixed permission sets designed to match common employee positions such as Accountant, Sales Rep, A/P Clerk, and Administrator. Standard roles cannot be modified, which means they serve as stable templates. Custom roles are copies of standard roles, or roles built from scratch, that an administrator tailors to the organization's actual structure. A custom role can have permissions added, reduced, or restricted to specific segments, and updating the custom role applies the change to every user assigned to it without touching individual user records. NetSuite recommends starting with a standard role as the template before customizing, rather than building a role from a blank permission list. Lightbridge ERP designs custom roles to match approval hierarchies, department boundaries, and audit requirements rather than copying standard roles unchanged.
What are role restrictions in NetSuite and how do subsidiary, department, and class restrictions work?: Role restrictions narrow the scope of a role's permissions to data matching a specific segment. Subsidiary restrictions limit the records a user can see to those belonging to designated subsidiaries, which is essential in OneWorld accounts where data across legal entities must be segregated. Department, class, and location restrictions filter records by the corresponding segment set on the user's employee record, so a department manager who has Edit access to transactions only sees transactions tagged to their department. Restrictions are configured on the role itself, not on individual users, so every user assigned the role inherits the same scope. When the Subsidiary restriction is set to Selected rather than All, an administrator must update the list whenever a new subsidiary is added. Lightbridge ERP designs restrictions alongside permissions so the scope of access matches the organizational structure from day one.
What are global permissions in NetSuite and should they be used?: Global permissions is an optional NetSuite feature that, when enabled, allows an administrator to assign permissions directly on an employee record rather than through a role. Those permissions apply to the employee across every role they hold in the account. When a global permission conflicts with a role-based permission, the global permission takes precedence. Oracle's own documentation and NetSuite practitioners generally recommend against relying on global permissions for regular access management. They introduce complexity that is difficult to audit because the effective access for a user depends on both their roles and their employee-record permissions, and that combination is harder to review than a clean role assignment. Lightbridge ERP treats global permissions as a last resort, appropriate for short-term temporary needs, and designs standard access through roles.
How does the principle of least privilege apply to NetSuite roles?: The principle of least privilege holds that each user should receive only the minimum access needed to perform their job function. In NetSuite, applying least privilege means starting role permission levels at View or Create rather than Edit or Full, scoping transactional permissions to the record types the role actually touches, using role restrictions to limit subsidiary or department scope where applicable, and never assigning Setup permissions to operational roles. It also means reviewing roles periodically to remove permissions that accumulated through incremental requests. Incorrectly over-permissioned roles introduce financial reporting risk: a user who can create AND approve a transaction, for example, can override the separation of duties that approval workflows are designed to enforce. Lightbridge ERP builds NetSuite role designs from a least-privilege baseline and documents the rationale for each permission granted.
How does NetSuite support segregation of duties through roles and permissions?: Segregation of duties is the principle that no single person should control an entire transaction cycle from initiation to approval and payment. NetSuite enforces it through role design: the person who creates a vendor record should not hold the permission to approve vendor payments; the person who records a journal entry should not hold the Journal Approval permission at a level that allows self-approval. Roles make this separation concrete because permissions are role-bound, and an administrator can verify segregation by comparing role permission sets. Common NetSuite SOD separation points include vendor management versus bill approval, purchase order creation versus purchase order approval, and journal entry creation versus journal entry approval. For how journal entry approval specifically enforces this separation, the Lightbridge ERP guide to journal entry approval covers the native preference and workflow options. Lightbridge ERP maps the organization's approval hierarchy to roles before configuring the system so the separation holds in practice.
How does NetSuite track role and permission changes through the audit trail?: NetSuite maintains two primary audit mechanisms relevant to roles and permissions. System Notes on each record capture every change to that record: who made the change, what changed, and when, and they also record which role the user was logged in under at the time. This means that if a permission was used to create or modify a record, the audit trail traces back to both the user and the active role. The Login Audit Trail records each login event, the role used to log in, and the session details, making it possible to identify roles that are assigned but rarely or never used, which is a common cleanup indicator. Both features are readable by administrators without additional configuration. Lightbridge ERP reviews System Notes and the Login Audit Trail as part of a NetSuite administration engagement to surface unused roles, over-permissioned active roles, and access patterns that deviate from the designed control model.

From a default role assignment to an access model your auditors can follow.

When NetSuite roles and permissions need to enforce least privilege and segregation of duties, Lightbridge ERP designs the access model end to end: vendor-neutral by design, delivered in-house, and documented for audit.

Talk to an ERP advisor NetSuite administration