NetSuite Roles & Permissions: Configuration Guide

Roles and permissions control who can see and do what in NetSuite. Every user is assigned one or more roles, and each role defines a set of permissions that determine access to records, pages, reports, and features. Getting this right is a balance between security (restrict access to sensitive data) and usability (let people do their jobs without calling IT).

How Roles Work

A role is a named collection of permissions. When a user logs into NetSuite and selects a role, that role's permissions determine:

• Which menu items appear in navigation
• Which record types the user can view, create, edit, or delete
• Which fields are visible or hidden on records
• Which reports and saved searches are accessible
• Which SuiteScript and workflow features are available

Users can have multiple roles. A controller might have a "Finance Manager" role for daily work and an "Administrator" role for system configuration. They switch between roles via the role selector in the top navigation.

Standard vs custom roles. NetSuite ships with standard roles (Administrator, Sales Manager, A/P Clerk, etc.) that cover common job functions. These can't be modified but can be duplicated and customized. Most companies create custom roles tailored to their specific organizational structure.

Creating a Custom Role

1. Navigate to Setup > Users/Roles > Manage Roles > New
2. Configure the basics:
   • Name: Descriptive name matching the job function (e.g., "Warehouse Manager - East Coast")
   • Center Type: Choose the UI layout (e.g., "Accounting Center" for finance roles)
   • Subsidiary restrictions: In OneWorld, restrict which subsidiaries this role can access
   • Two-factor auth required: Enable for roles with sensitive access

Permission Categories

Permissions are organized into categories on the role record:

Transactions: Permission to create, view, edit, or full access for each transaction type (invoices, purchase orders, journal entries, etc.). Set at four levels:

• None — no access
• View — read-only
• Create — can create new records but not edit existing ones
• Edit — can create and modify records
• Full — can create, modify, and delete records

Reports: Access to specific report categories. Users only see reports they have permission for in the Reports menu.

Lists: Access to record types like customers, vendors, items, employees. Same permission levels as transactions.

Setup: Access to configuration pages. This is where you control who can modify the system itself — custom fields, workflows, integrations, and account settings.

Custom Record: Permissions for any custom record types in the account. Each custom record type has its own permission entry.

Permission Levels in Detail

Transaction permissions example

For an Accounts Payable Clerk role:

Transaction Type	Permission Level	Rationale
Vendor Bill	Edit	Core job function — enter and edit bills
Vendor Payment	Create	Can create payments but not modify approved ones
Purchase Order	View	Needs to reference POs when entering bills
Invoice	None	Not relevant to AP function
Journal Entry	None	Finance manager handles journals
Expense Report	Edit	Processes employee expense reports

List permissions example

Record Type	Permission Level	Rationale
Vendors	Edit	Maintains vendor records
Customers	View	Reference only
Employees	View	To process expense reports
Items	View	Reference for bill entry
Subsidiaries	None	No need for entity management

Restricting Data Access

Record-level restrictions

Beyond permission levels, you can restrict which specific records a role can access:

Subsidiary restrictions (OneWorld): Limit the role to specific subsidiaries. A US subsidiary finance team can't see European subsidiary data.

Department/class/location restrictions: Filter records by these segments. A location manager only sees transactions for their location.

Employee restrictions: Roles can be restricted to only see records related to specific employees or the user's own records. This is common for expense report roles where employees should only see their own expenses.

Field-level restrictions

Use field-level security to hide sensitive fields from specific roles:

1. Go to the custom field or standard field customization
2. Under the Access subtab, set field visibility per role
3. Options: Normal (visible), Hidden (not visible), Disabled (visible but not editable)

Common field-level restrictions:

• Hide cost fields from sales roles
• Hide compensation fields from non-HR roles
• Disable price override fields for junior sales staff
• Hide margin calculations from customer service

Form-level restrictions

Different roles can see different custom forms for the same record type. A sales order form for the sales team might show different fields than the form used by the fulfillment team:

1. Create custom transaction/entry forms for different audiences
2. On the form, select which roles can access it under Roles subtab
3. Set a preferred form per role so users automatically see the right layout

Global Permissions

Some permissions apply account-wide rather than per record type:

Allow Web Services Access — required for roles used in integrations (REST/SOAP web services)

SuiteAnalytics Workbook — access to the SuiteAnalytics reporting tool

SuiteScript — required for roles that use custom scripts

Custom Segments — access to custom segment configuration

Log in Using Access Tokens — required for token-based authentication in integrations

Integration role best practices

Roles used for API integrations (SuiteTalk, RESTlet, Token-Based Authentication) should:

• Have only the specific permissions needed for the integration's data access
• Enable "Log in Using Access Tokens" and "Allow Web Services Access"
• Never use the Administrator role for integrations
• Use a dedicated "Integration" or "API" user that is not tied to an employee who might leave the company

Security Best Practices

Principle of least privilege

Start with no permissions and add only what the role needs. It's easier to add a missing permission when someone reports it than to audit an overly permissive role after a data incident.

Separate admin functions

Don't give Administrator access to users who only need it occasionally. Create a custom admin-lite role with specific setup permissions. Reserve full Administrator for system architects and during implementation only.

Audit role assignments regularly

Run a saved search on employee records showing role assignments. Review quarterly:

• Are departed employees still active?
• Do current roles match current job functions?
• Are there users with Administrator access who don't need it?

Employee Saved Search:
- Filters: Is Inactive = No
- Columns: Name, Role, Department, Last Login
- Sort: Last Login (ascending) to find inactive accounts

Two-factor authentication

Enable 2FA on roles with access to:

• Financial data (GL, bank reconciliation, payment processing)
• Personal data (HR, payroll, employee records)
• System configuration (Administrator, custom roles with Setup permissions)
• Integration credentials (web services, token management)

IP address restrictions

Restrict sensitive roles to specific IP ranges:

1. On the role record, check Restrict this Role by IP Address
2. Define allowed IP addresses at Setup > Company > Company Information (company-wide) or on individual employee records
3. Users can only access NetSuite with this role from approved IP addresses

For more granular control, enable the IP Address Rules feature at Setup > Company > Enable Features > Company (SuiteCloud tab), which allows rule-based IP restrictions per role. Oracle recommends 2FA as the preferred alternative to IP restrictions for most scenarios.

2026.1 Role & Security Updates

NetSuite 2026.1 introduced several changes relevant to role security:

Multiple simultaneous sessions now require opt-in. Administrators must explicitly enable this feature, and only users assigned to roles with two-factor authentication enforced can use multiple sessions. Navigate to Setup > Company > Enable Features to configure this.

Mandatory login notifications. Admins can configure a compliance message displayed at login that users must acknowledge before accessing the account. This supports organizations subject to security frameworks like NIST that require explicit acknowledgment of access policies.

CDL restriction updates. Class, department, and location role restrictions on account records now include unassigned values, providing more granular control over financial data access.

Testing Roles

Before rolling out a new or modified role:

1. Create a test user with only the new role assigned
2. Log in as the test user and walk through common workflows
3. Verify access — can they reach everything they need?
4. Verify restrictions — can they NOT reach things they shouldn't?
5. Test edge cases — saved searches, reports, SuiteScript pages, web store access

NetSuite's Login Audit Trail (Setup > Users/Roles > View Login Audit Trail) helps monitor role usage and identify permission issues after rollout.

Common Mistakes

Cloning Administrator. Duplicating the Administrator role and removing a few permissions seems efficient but leaves too many doors open. Start from scratch with a minimal role instead.

Ignoring custom records. Custom record permissions are separate from standard record permissions. A new custom record type starts with no permissions for any role — you must explicitly add them.

Forgetting script access. SuiteScript-powered features (custom buttons, Suitelets, scheduled scripts) require the SuiteScript permission on the role. If a workflow runs a script, the triggering user's role needs this permission.

Not restricting saved searches. Saved searches can expose data beyond what a role's record permissions intend. A user with View access to customers can create a saved search that returns all customer data. Use the Audience tab on saved searches to restrict who can run them.

Frequently Asked Questions

How do I create a custom role in NetSuite?expand_more

What are the permission levels for NetSuite roles?expand_more

Can a NetSuite user have multiple roles?expand_more

How do I restrict data access by subsidiary in NetSuite?expand_more

What is the best practice for setting up NetSuite roles?expand_more