Most NetSuite accounts do not start out with messy access. They get there one small request at a time. A new hire needs to run reports, someone covering for a colleague needs temporary approval rights, a contractor needs to see a handful of records. Every one of those changes made sense on the day it happened. Six months later, nobody can say with confidence who can do what.
A permissions review fixes that without turning into a freeze on access requests. The goal is not to lock everything down. It is to know what access exists, remove what no longer has a reason to exist, and keep a process light enough that people actually follow it.
Photo by Dan Nelson on Pexels
NetSuite Permissions and Roles Are Two Different Things
NetSuite separates the two concepts, and keeping them straight makes every audit easier. Permissions govern access to record types, tasks, and pages. Permissions are associated with roles, and roles are assigned to users.
Those users are not only employees. A role can be assigned to employees, vendors, partners, or customers, which means your review has to look past the payroll list. Standard roles for specific business functions ship with predefined sets of permissions, and Administrators can create custom roles. That flexibility is exactly what makes drift possible over time.
How to See What a Role Actually Grants
Start with the tools already inside NetSuite instead of a spreadsheet you maintain by hand. Go to Setup > Users/Roles > Manage Roles, click a role, and review the permissions listed for it. The same path works for the Administrator role if you want to see the full list of permissions assigned to it.
That screen answers the most common question in any review: what does this role actually let someone do? Work role by role rather than user by user. You will usually find the same custom role handed out to people with very different jobs, and that is where the cleanup starts.
The Five Permission Types
Permissions are divided into different types, and grouping a review by type keeps the work manageable:
- Transactions
- Reports
- Lists
- Setup
- Custom Records
Setup access and permissions on custom record types deserve the most attention. Transaction access tends to be understood because it maps to daily work. Setup permissions and anything tied to custom records accumulate quietly and often grant more than a person's job requires.
The Five Permission Levels
NetSuite supports five general permission levels: None, View, Create, Edit, and Full. Full is reserved for narrow cases because it includes more than everyday data entry.
During a review, treat Full as a flag. Every Full entry should have an owner who can explain why it is needed. Edit is frequently the level someone meant to request when they asked for the ability to change records. If you are unsure how two levels differ for a specific permission, check the official documentation for that permission rather than guessing. The distinction matters most on Setup permissions and anything touching financial or master data.
Use the Permissions Worksheet to Answer "What Does This Do?"
Oracle publishes a Microsoft Excel worksheet that lists how most NetSuite permissions are used. It answers two questions quickly: what happens when a permission is assigned, and which permission is required to provide access to a specific task or page.
The spreadsheet format lets you search and sort fields in whatever way works best, and each column has filters. When a manager asks for access to a page, you can look up the exact permission needed instead of granting a broad role and hoping it covers the request.
Build Custom Roles from Copies of Standard Roles
NetSuite documentation is direct on this point: it is best to start with a copy of the standard roles built into NetSuite before you customize them. Giving users only the access they need helps avoid showing restricted pages, records, and data. You can then add or remove permissions from the copy until it fits the job.
Copies also make future reviews easier. The standard role stays intact as a reference point, so you can compare your customized version against it when something breaks or when a new administrator takes over.
Adding a Permission Without Over-Granting
When a request comes in, edit the role and go to the Permissions tab, then add the permission there. Resist the shortcut of assigning an extra broad role to a user just to close one gap. Stacked roles are one of the most common ways people end up with more access than anyone intended, and they are the hardest kind of access to untangle later.
Permissions That Control Permissions
Some permissions govern the roles system itself, which puts them in a different risk category. Add/Edit Permission on Roles allows a user to add or edit permissions on various roles. Bulk Manage Roles allows changes across roles in volume.
A small number of trusted administrators should hold these, and the list of who holds them belongs in every review. If a permissions cleanup goes wrong, it is usually because someone held role-editing rights without anyone tracking it.
Review Users as Well as Roles
Roles are only half the picture. The same Setup > Users/Roles area is where you confirm who currently has access. Two checks pay off quickly.
First, look for accounts belonging to people who have left, changed roles, or never started. Second, look for users holding multiple roles where one broad role makes the others redundant. In both cases, the fix is removal, not a new process. Vendor, partner, and customer users are easy to overlook because they do not show up in typical HR reporting, so put them on the review list explicitly.
Common Role and Permission Mistakes
Most access problems trace back to a short list of habits:
- Granting Full instead of the narrower level that matches the request.
- Assigning an additional role to close one gap instead of editing the existing role.
- Leaving custom roles in place long after the project that created them ended.
- Letting the group of people who can edit roles grow without review.
- Never comparing customized roles back to the standard roles they came from.
A Review Rhythm That Does Not Slow Anyone Down
A permissions review that happens once and never again decays within months. A lighter, repeating cadence works better than a large annual project:
- Schedule the review at a fixed interval so it is expected rather than disruptive.
- Walk the role list from Manage Roles, one role at a time.
- Confirm current user assignments and remove stale access.
- Check who holds role-editing permissions.
- Document every change and the reason behind it.
- Close the loop with requesters so they know why access changed.
Keep the changes visible. Teams slow down when access disappears without explanation, and that friction is what kills future reviews. A short note to the affected manager is usually enough, and it protects the process from being seen as an obstacle to getting work done.
When to Bring In Help
If your account has years of custom roles, stacked assignments, and no documentation, an outside review can be faster than rebuilding the picture internally. Zastro works with growing businesses on NetSuite implementation, ongoing support, and ERP health checks, including access and role reviews. You can reach the team through zastro.com to talk through what a review would cover for your account.
Frequently Asked Questions
How do I check what permissions a role has in NetSuite?
Go to Setup > Users/Roles > Manage Roles, then click the role you want to inspect. The role record shows the permissions assigned to it along with their levels. The same path lets you view the full permission list for the Administrator role if you need a baseline for comparison. Reviewing roles this way is faster than maintaining your own tracking spreadsheet.
What are the five permission levels in NetSuite?
NetSuite supports five general permission levels: None, View, Create, Edit, and Full. None removes access, View is read-only, Create and Edit allow progressively more change, and Full is reserved for narrow cases because it includes more than everyday work requires. During a review, treat every Full entry as something that needs a documented reason behind it.
Should I customize standard NetSuite roles or copy them?
Start with a copy of the standard roles built into NetSuite, then add or remove permissions from that copy. Giving users only the access they need helps avoid showing restricted pages, records, and data. Keeping the original standard role untouched gives you a reference point for future comparisons and troubleshooting when behavior changes.
How do I find out what a specific NetSuite permission does?
Oracle publishes a Microsoft Excel worksheet that lists how most NetSuite permissions are used. It shows what happens when you assign a specific permission and which permission provides access to a specific task or page. The format is searchable and sortable, and each column includes autofilters, so you can look up permissions by name or by the task you are trying to enable. When permission dependencies or role interactions become difficult to troubleshoot, Zastro can help identify the exact permissions required while maintaining security best practices.
What is the difference between a role and a permission in NetSuite?
Permissions govern access to record types, tasks, and pages. Permissions are associated with roles, and roles are assigned to users, who can be employees, vendors, partners, or customers. So a permission answers what someone can do, while a role is the package that carries a set of permissions and gets assigned to a person.
