Netsuite User Management Guide

• Model type: role-based
• Description: NetSuite uses a role-based access control (RBAC) model. Each user is assigned one or more roles. Each role contains a set of permissions across record types, transaction types, lists, and reports. Permissions within a role are set at four levels: View, Create, Edit, and Full. Users can hold multiple roles simultaneously and switch between them within a session. NetSuite provides a library of standard predefined roles (e.g., Accountant, Sales Manager, A/P Clerk) and allows administrators to create custom roles by duplicating and modifying existing ones.
• Custom roles: Yes
• Custom roles plan: Available on all NetSuite subscription tiers; no additional plan required for custom role creation
• Granularity: Permission control is at the individual record type, transaction type, list, and report level, each with four access levels (View, Create, Edit, Full). Restrictions can also be applied by subsidiary, department, class, and location using segment-level restrictions.

1. Log in as Administrator or a user with the 'Manage Users' permission.
2. Navigate to Setup > Users/Roles > Manage Users.
3. Click 'New User' or locate an existing employee record to grant system access.
4. If creating from an employee record: open the employee record, go to the 'Access' subtab, check 'Give Access', and enter the user's email address as their login.
5. Set a password or select 'Send New Password' to email a temporary password to the user.
6. Assign one or more roles using the 'Roles' subtab on the Access section.
7. Configure authentication settings (e.g., require MFA, SSO) as needed.
8. Save the record. The user will receive a welcome/activation email if 'Send New Password' was selected.

Required fields: Email address (used as login identifier), Name (first and last), At least one assigned role, Password or 'Send New Password' selection

Watch out for:

• Users must have an employee, vendor, partner, or contact record in NetSuite before system access can be granted; access is attached to an existing entity record, not created independently.
• Email address must be unique across the NetSuite account; duplicate emails will cause an error.
• MFA (multi-factor authentication) is required by Oracle for all Administrator-level users and for users accessing sensitive data; this cannot be disabled for those roles.
• SSO-only accounts still require a NetSuite entity record; JIT provisioning via SAML can create the entity record on first login if configured.
• Assigning a role does not automatically grant access to all data within that role's scope-subsidiary, department, class, and location restrictions may further limit what the user can see.
• New users consume a license seat immediately upon activation; confirm available seat count before provisioning.

• Can delete users: No
• Delete/deactivate behavior: NetSuite does not allow deletion of user or employee records that have associated transactions, records, or audit history. The standard approach is to inactivate the user, which revokes login access while preserving all historical data and record associations. The 'Inactive' checkbox on the employee/entity record is the primary mechanism. Inactivating a user immediately prevents login but retains all owned records, audit trails, and transaction history intact.

1. Navigate to Setup > Users/Roles > Manage Users, or open the employee's record directly via Lists > Employees > Employees.
2. Open the employee or entity record for the user to be deactivated.
3. Go to the 'Access' subtab.
4. Uncheck 'Give Access' to immediately revoke login access without fully inactivating the employee record, OR
5. Check the 'Inactive' checkbox on the employee record to inactivate the entire record (removes the user from active lists and revokes access).
6. Save the record.
7. Optionally, reassign any open tasks, approvals, or workflows owned by the departing user before or after deactivation.

Watch out for:

• Inactivating a user does not automatically reassign open approval workflows or pending tasks; these must be manually reassigned to prevent process blockages.
• TBA (Token-Based Authentication) tokens tied to the inactivated user are immediately invalidated; any automated integrations using those tokens will break and require reconfiguration.
• If the user is the sole approver in a workflow or approval routing rule, those workflows will stall after inactivation; update approval routing before deactivating.
• Inactivated users still appear in historical transaction records and audit logs with their original name, which is expected behavior for compliance purposes.
• Unchecking 'Give Access' (without marking the employee record Inactive) removes login access but keeps the employee active in HR/payroll processes-useful for employees on leave.
• NetSuite does not send an automatic notification to the user upon deactivation; any offboarding communication must be handled externally.

• Where to check usage: Setup > Company > View Billing Information - displays current licensed user count and active user count. Also accessible via Setup > Users/Roles > Manage Users, which lists all active users and their assigned roles.
• How to identify unused seats: Navigate to Setup > Users/Roles > Manage Users and filter by 'Last Login' date (if the column is available or added via customization) to identify users who have not logged in recently. NetSuite does not provide a native 'inactive users' report out of the box; a saved search on the Employee record type filtered by 'Give Access = True' and sorted by last login date can be constructed to identify candidates for deactivation.
• Billing notes: NetSuite licensing is sold as an annual subscription negotiated directly with Oracle or a NetSuite partner. There is no self-serve monthly billing. The base platform license starts at approximately $999+/month; user seats are priced per named user per month and added to the annual contract. A minimum of 10 users is typically required. Additional modules (e.g., Advanced Inventory, Payroll, CRM) are priced separately at $300–$1,500+/month each. License changes (adding or removing seats) generally require a contract amendment and may not take effect until the next renewal period depending on contract terms.

NetSuite has no native SCIM support and no Microsoft Entra automatic provisioning connector, so every provisioning and deprovisioning action is manual by default. Admins must navigate to Setup > Users/Roles > Manage Users, locate or create the entity record, configure the Access subtab, assign roles, and set authentication options individually per user.

Role management compounds the effort. Custom roles cannot be cloned via a wizard - admins duplicate a standard role and modify it manually, then audit permissions across four access levels (View, Create, Edit, Full) for every record type, transaction type, and list in scope.

There is no native last-login report; identifying unused seats requires building a saved search on the Employee record type filtered by Give Access = True, sorted by last login date.

Offboarding carries its own risk surface. Inactivating a user does not automatically reassign open approval workflows or pending tasks, and any Token-Based Authentication tokens tied to that user are immediately invalidated - breaking integrations silently if not caught in advance.

The absence of SCIM is the most consistently cited frustration in the NetSuite administrator community.

For a platform at this scale and price point, the expectation of automated provisioning via a standard protocol is reasonable, and its absence forces reliance on SuiteScript or third-party middleware for anything resembling lifecycle automation.

MFA enforcement for Administrator roles is a recurring operational pain point, particularly for service accounts and integration setups where token-based authentication must be used instead. The SuiteCloud Plus License requirement for higher API concurrency adds cost for organizations that do pursue automation.

Role permission complexity is also widely noted. With hundreds of permission combinations across record types and no native role-auditing tooling, maintaining least-privilege access at scale is a sustained administrative burden.

Common complaints:

• No native SCIM support despite being a major enterprise ERP platform; automated provisioning requires custom SuiteScript or third-party middleware.
• Microsoft Entra ID (Azure AD) automatic provisioning is not supported; Microsoft's own documentation confirms NetSuite does not support the SCIM endpoint required for Entra provisioning.
• MFA enforcement for Administrator roles complicates service account and integration setups; token-based authentication (TBA) must be used for API integrations instead.
• SuiteCloud Plus License is required for higher API concurrency needed in bulk provisioning scenarios, adding cost for organizations with automation needs.
• No native 'last login' report makes it difficult to identify unused seats without building a custom saved search.
• Role permission management is complex and time-consuming; with hundreds of permission combinations, building and auditing custom roles requires significant administrator effort.
• License seat changes require contract amendments rather than self-serve adjustments, creating delays when headcount changes rapidly.
• JIT provisioning via SAML creates user records on first login but does not handle deprovisioning; offboarding must still be done manually in NetSuite.
• Inactivating a user does not automatically reassign their open workflows or approval tasks, requiring manual cleanup to avoid process stalls.
• External portal users (Vendor Center, Customer Center) have a separate and less intuitive management flow compared to internal users.

NetSuite is appropriate for organizations that have dedicated NetSuite administrators and can absorb the manual overhead of entity-record-based provisioning. The role model is powerful but requires ongoing investment to maintain correctly - especially as headcount grows or org structures change.

Organizations with high employee turnover or frequent role changes should plan for the workflow-reassignment gap at offboarding: if the departing user is a sole approver in any routing rule, those workflows stall immediately upon inactivation. Approval routing must be audited before deactivation, not after.

Teams expecting plug-and-play identity provider sync (Entra, Okta SCIM) should note that Okta uses a proprietary NetSuite connector rather than SCIM, and Entra automatic provisioning is not supported at all. Budget for middleware or custom SuiteScript if automated lifecycle management is a requirement.

Bottom line

NetSuite's manual provisioning model is functional but labor-intensive at scale. Every app in your environment that depends on accurate, timely access data will feel the lag when provisioning and deprovisioning are handled record-by-record through the admin console.

The lack of SCIM, the entity-record prerequisite, the absence of a native last-login report, and the workflow-reassignment gap at offboarding are not edge cases - they are routine friction points that compound with headcount.

Organizations that treat NetSuite access management as a set-and-forget task will accumulate stale seats and orphaned approvals. Those that invest in saved searches, documented role libraries, and a pre-offboarding checklist will manage it more reliably, but the investment is real and ongoing.