NetSuite Administrator Best Practices: Managing Users, Roles, Permissions, and Controls

Give People the Access Their Work Needs

A new employee needs access today. A manager asks for a wider role to fix an error. A contractor finishes a project, but their account stays active. These are the moments when a clear administration process matters.

We conducted a documentation review of Oracle NetSuite guidance, CIS Controls, and NIST access-control principles for this guide. Our analysis turns those sources into practical checks for administrators. The examples are suggested test cases, not results from a customer account or a live system study.

Oracle defines a role as an access configuration that controls the pages and tasks available to a user. It recommends using standard roles as templates for custom roles because standard roles cannot be edited directly.^[1]

Start with a simple rule: every account needs an owner, every role needs a purpose, and every access change needs evidence of approval.

Keep an Account List You Can Trust

CIS Safeguards 5.1 and 5.5 call for inventories of user, administrator, and service accounts. They recommend checking that active accounts are still authorized at least quarterly. Safeguard 6.2 calls for a process to revoke access when employment, rights, or roles change.^[2]

Use a user export as a starting point, then have managers confirm the business need. Include contractors and integration accounts. A familiar name is not proof that access is still needed.

• Identify the owner: record the person, team, manager, and business purpose.
• List all access: capture assigned roles and any direct permissions that need separate review.
• Set an end date: track temporary access and contractor expiry in the request record.
• Record the decision: keep the reviewer, date, changes requested, and completion evidence.

When someone changes teams, review their old access before adding the new role. Otherwise, the transfer can leave them with duties from both jobs. For departures, agree on a cutoff time with HR and the manager, then verify that removal is complete.

Build Roles Around Tasks, Then Compare Them

Name roles by the work they support, such as “AP Bill Entry” or “Sales Order Review.” Avoid role names tied to a single employee. Keep a short description of the tasks, records, and approval limits the role is meant to cover.

Oracle groups role permissions into areas such as Transactions, Reports, Lists, Setup, and Custom Records. It also provides Setup > Users/Roles > Show Role Differences to compare permissions across roles.^[3]

Use that comparison when a user reports a missing task. Find the specific permission behind the error and test the smallest change that solves it. Avoid adding broad access just because another role happens to work.

Test Permissions and Record Restrictions Separately

Oracle distinguishes permissions from restrictions: a permission grants access to a record type or task, while a restriction narrows the records available. Oracle also notes that global permissions, when enabled, can be assigned directly to employees outside their roles.^[4]

That means a role checklist alone is not enough. Review the employee's access as well as the role. Check relevant subsidiary, department, and other record restrictions in your account. Confirm the behavior with a test user rather than relying only on the setup screen.

For example, test whether a sales user can open an allowed customer, whether they can see a customer outside their scope, and whether a search or export exposes extra information. These are proposed checks; the expected result should come from your company's approved access rules.

Separate Sensitive Duties Across the Whole User

NIST SP 800-53 describes separation of duties in control AC-5 and least privilege in AC-6. Together, they support splitting sensitive work and granting only the access needed for assigned tasks.^[5]

Apply that principle to the person, not just each role in isolation. A user with two well-designed roles may still be able to complete both sides of a sensitive process by switching roles.

Ask your finance owner to identify combinations that need separation. Examples include changing vendor bank details and releasing payments, entering journals and approving them, or changing access and reviewing those same changes. These are review prompts, not a claim that every account has identical workflows.

Where a small team cannot fully split duties, agree on a separate review with a named owner and clear evidence. Record the exception, why it is needed, and when it must be reassessed.

Use One Clear Path for Access Changes

Keep the process short enough that people will follow it. A five-step flow gives the requester, approver, and administrator a shared view of what happens next.

Use the same record for urgent requests. If emergency access is approved, give it a clear expiry and review the activity afterward. Assign someone to remove it; a date written in a ticket does not remove access by itself.

Protect Administrator and Integration Access

Oracle requires two-factor authentication for Administrator and other highly privileged roles, including in sandbox, development, and Release Preview accounts. That requirement cannot be removed. Oracle also states that roles requiring 2FA cannot use user credentials for API authentication.^[6]

Keep routine work in an appropriate business role. Use privileged access only for the task that needs it. Document recovery steps and make sure an approved backup administrator knows how to use them.

For integrations, define a separate purpose, business owner, and access scope. Confirm that the authentication method is supported by the connector and NetSuite interface in use. Test credential changes before a planned cutover and verify the old credential is revoked afterward.

When an employee leaves, check whether integrations depend on credentials they own. Transfer ownership through an approved process so removing the person's access does not become a reason to leave it active.

Keep Evidence That Explains What Changed

Oracle says System Notes capture details such as who changed a record, when the change happened, the interface used, and old and new values. Users, scripts, and apps cannot edit those notes. Oracle distinguishes System Notes from System Notes v2, so confirm which system covers the records you need to review.^[7]

Pair the available change history with the request and approval. A log can show an action, but the request explains why it was allowed. Verify coverage for the specific record and field instead of assuming one report captures every kind of change.

• Keep the original request and business approval.
• Save the relevant role comparison or configuration record.
• Record the test user, expected results, and actual results.
• Link the production change to the administrator and date.
• Close the request only after access and any expiry steps are verified.

Make Reviews Part of the Working Calendar

Use a schedule your team can sustain. The cadence below is a suggested operating plan. Adjust it for the sensitivity of your data, staff changes, and internal policies.

Begin with one business area if the account needs cleanup. Review its users, tighten its roles, test the controls, and document what you learned. Then apply the same process to the next team. Keep unresolved items visible until an owner confirms they are fixed.

References

Sources reviewed September 23, 2026. Product behavior should be checked against the features and configuration in your account.

1. Oracle NetSuite: NetSuite Roles Overview.
2. CIS Controls v8.1: Account Management and Access Control Management (Controls 5 and 6).
3. Oracle NetSuite: NetSuite Permissions Overview.
4. Oracle NetSuite: Permissions and Restrictions.
5. NIST SP 800-53 Rev. 5: Separation of Duties (AC-5) and Least Privilege (AC-6).
6. Oracle NetSuite: Mandatory Two-Factor Authentication for NetSuite Access.
7. Oracle NetSuite: System Notes Overview.