About Salto: Salto helps you and your team deploy, track, and manage your NetSuite customizations effortlessly. Learn more here.

‍

NetSuite roles and permissions are essential to any NetSuite environment. Permissions should be granted with the ‘principle of least privilege’ in mind to ensure that users only have access to view/create/edit/delete records required to perform their job. By having separate feature permissions and permission levels, NetSuite allows for a high level of flexibility when it comes to creating custom user roles. Despite the flexibility, there are still some challenges to overcome with specific role permissions, which we will explore as part of the FAQ below.

An Introduction to NetSuite User Roles and Permissions

NetSuite roles and permissions are the foundation for granting users access to specific areas of the system, as well as limiting access to those same areas. Access to different record types, features and functionality are almost exclusively governed by NetSuite role permissions, with some exceptions. In this article we are going to focus on the user roles in NetSuite.

NetSuite separates the user role permissions into a number of different categories, such as transactions, setup and custom. Each category includes a permission list that is focused on a particular area of the system. The NetSuite Administrator role has Full permission (where possible) to all user role permissions, but other roles will have varying permission levels.

NetSuite Permission Levels 

• View - User can only see existing data e.g. view a sales order
• Create - User can create new records e.g. create a new invoice
• Edit - User can modify existing data e.g. edit an existing sales order
• Full - User has all access levels (view, create, edit and delete) for that specific function

Salto Tip: Some user role permissions only have one permissions level. Some only have “Full” permission level such as “Import CSV File” and others only have “View” permission level such as “Transaction Detail” along with many other reports permissions.

There is no standalone report that provides the NetSuite permissions list, because each NetSuite account is different and will have access to different functionality. In turn, this means the list of “Custom Record” role permissions will differ account by account. That being said, you can access a NetSuite permissions list in Excel format from SuiteAnswers. Be sure to click on the hyperlink and then download the file entitled “NetSuitePermissionsUsage.xls”. The file name will include the version of NetSuite the role permissions are related to. It will be the latest version. 

You should plan to review this periodically and certainly with each new NetSuite release, as NetSuite introduces new NetSuite user permissions during many release cycles. Back in the 2021, NetSuite introduced a new role permission entitled “Vicarious Email” that only has a permission level of “Full” available. This role permission allows the user to send email on behalf of other users, including via SuiteScript. Prior to 2021 this was not necessary and did result in challenges for some NetSuite end users that did not pay close attention to the release notes that year or leverage their Release Preview account.

This Excel file is the best NetSuite role permissions report available across all NetSuite accounts, however if you are looking for something more specific to your NetSuite environment you should leverage the “Show Role Differences” page.

When using this functionality you should highlight all user roles in the “Compare To” section and ensure the “Only Show Differences” checkbox is unchecked. The “Base Role” is irrelevant, but I generally select Administrator for consistency.

Note, if you select more than 100 user roles for comparison you will receive a warning message from NetSuite. If you have over 100 active user roles in your NetSuite environment then it is probably time to start thinking about consolidating those roles to simplify user access (and reduce the administrative burden associated with managing that many roles!)

‍

‍

Getting roles and permissions right is critical. Why?

NetSuite roles and permissions dictate the end user experience in NetSuite i.e. what they can and cannot do within the system. As such, there is often a tendency to assign role permissions and permission levels that exceed the requirements for a given role for fear of impacting a user’s ability to perform their job. Instead, deeper thought should be given to the appropriate access level required for each NetSuite role permission to ensure that you adhere to the principle of least privilege.

Granting the incorrect role permission or an inappropriate permission level can have significant system implications as well as introduce business process risk. For example, consider a user role that had the permission to create vendor records, create vendor bills and create vendor payments. This would introduce a significant business process risk, without the appropriate risk mitigating controls in place. Read on to find out more.

Likewise, not granting the appropriate role permission or permission level can have other implications, such as not allowing the finance team to close the books on time due to an inability to run specific month close checklist processes due to role permission deficiencies.

‍

Exploring the permissions

There are many configuration options when customizing a NetSuite role. This guide will walk you through some of these key configuration options.

• General Configuration
• Subsidiary Configuration
• Permissions
• Restrictions
• Forms

General Configuration

• Name - Give each custom role created a unique name that describes to function of the role e.g. [Company Name] A/P Specialist. 
• Center Type – Drives the general layout and navigation of NetSuite menus. NetSuite roles and permissions templates are included out of the box.  Accounting type roles default to the “Accounting Center” center type, sales type roles default to the “Sales Center” etc. These are typically used as a template when creating customized roles and the value cannot be changed once the role has been created.

Salto Suite Tip: Consider using the “Classic Center” for all roles. This will make NetSuite navigation consistent across the entire environment and make for easier ongoing NetSuite support and end user training.  There would be some upfront investment in creating a new role vs using a pre-configured role, but this could pay dividends in the long term.

• Employee Restrictions – This field determines whether a user with this role should have access restricted to specific NetSuite records based upon certain values on the employee record. This functionality can be especially helpful when the sales team operates within NetSuite and should have access restricted to records for themselves and their team.
• Other checkboxes – These will vary depending upon the NetSuite features enabled in the environment. A universal checkbox is for “Core Administrative Permissions”. When checked, the role will have similar permissions to that of the Administrator role, although the role can still be customized to restrict access to other parts of the system that may contain sensitive information for example.
  ‍

‍

Subsidiary Configuration

Subsidiary restrictions on NetSuite user roles are pretty self-explanatory. Be mindful when using the “Selected” option that the system administrators will need to maintain the multi-select subsidiary values as and when new subsidiaries are added to the system. 
‍

Given the various subsidiary restriction options available on any given user role, if we needed to change an employee subsidiary, the records that they can access in the system may change.

If their user role has subsidiary restrictions set to “User Subsidiary” and you change the subsidiary on their employee record that is going to directly impact what they can and cannot see in NetSuite. If however the restriction is set to “All” then changing the subsidiary on the employee record will have no impact.

‍

‍Permissions

Permissions control the NetSuite processes and records a user can interact with. Permission levels vary by permission, but generally have four levels:

• View
• Create
• Edit
• Full (allows for record deletion, grant sparingly)

NetSuite separates the role permissions into five broader categories:

• Transactions – Determines access to NetSuite transaction records and ability to approve those transaction records. For most roles, these permissions will be limited, as each role will perform a specific function e.g. A/P Specialist should not need access to “Invoice” or “Invoice Approval” transaction permissions. Keep in mind that transaction role permissions impact a user’s ability to configure SuiteFlow i.e. build workflows, for those transactions.

• Reports – Determines access to the broader NetSuite financial reporting available to users. Roles working closely with financial reporting will typically have most of these permissions assigned.

Salto Suite Tip: Give thought as to which roles should have access to the “Report Customization” role permission. Changes to custom financial report layouts can be challenging to find/revert, so it is recommended assigning this permission to roles where it is expected to have some familiarity with NetSuite financial report customization and working with custom financial report layouts.

• Lists – Essentially access to all NetSuite records that are not transactions nor custom records. Think customers, vendors, employees, etc. There are some permissions that could arguably be included under other categories e.g. “Memorized Transactions”, so be mindful that not all user role permissions are 100% intuitive when considering the respective permission category. Some permissions are more administrative by nature and should be locked down to a small subset of users, “Mass Updates” for example.

• Setup – These role permissions are largely administrative, but there are some role permissions under this category that should be considered for a broader range of roles. Consider “Import CSV File” for environments that allow end users to process their own CSV imports for records they have access to. The “SAML Single Sign-on” permission is needed to allow a role to authenticate with NetSuite via SSO. As more and more companies move to SSO, this permission will become more of a standard permission for NetSuite roles.

• Custom Record – For any SuiteApps installed or custom records created in the system, user access can be granted to the specific records or groups of records in the case of a SuiteApp. These role permissions are generally modified during a new SuiteApp implementation to allow users to access the solution and interact with it as needed.

At the same time, these are often NetSuite user role permissions that are overlooked, especially when working with NetSuite native bundles, such as the Electronic Bank Payments bundle. Do not be surprised to see a NetSuite permission error for payment batches if the Custom Record role permissions have not been configured correctly, for example:

Permission Violation: You need the 'Custom Record Types' permission to access this page. Please contact your account administrator when editing or creating Entity Bank Details for entity records.

‍

Roles and Permissions Restrictions

Generally, not used except for specific circumstances. For example, if you wanted to restrict a role to specific NetSuite records based upon the “Class”, “Department” and “Location” set on the user employee record. Note these are the three out of the box segments. Imagine you are a product-driven business and use the “Class” segment to separate NetSuite records by product line. You could leverage this functionality to ensure employees focused on product line A only have access to product line A NetSuite records, likewise for product line B, C, etc. 
‍

‍

Forms

NetSuite forms are a great way to drive what the user sees and how they interact with NetSuite. As a result, in a NetSuite environment with many tailored forms it is advisable to restrict form access, so that users only interact with records and fields on those records that they need to work with. Perhaps the A/P Specialist requires access to 90% of fields on the “Bill” transaction, whereas the A/P Manager may only need access to 50% of the fields to facilitate review and approval. 

Other companies opt for region specific forms given requirements will likely differ by region for localization purposes. If user roles are then aligned with regions, forms can be associated with corresponding in-region roles to limit the fields the user interacts with and helps to avoid confusion among end users where fields are applicable to a specific region and not applicable to others.

Salto Suite Tip: Where possible, restrict the record type to a specific form (by checking the “Restricted” check box). If you do not, maintenance quickly becomes a challenge, especially when additional forms are added to the system over time.

Segregation of duties considerations

Coming back to the earlier example of a user role that had the permission to create vendor records, create vendor bills and create vendor payments. This is a clear and obvious segregation of duties conflict. While the risks can largely be mitigated through reviews, approvals, etc. it is highly recommended, where possible, to have separate user roles to manage these operational tasks. As such, an ideal state would be:

1. Vendor record creation – Managed by NetSuite role “Vendor Manager”
2. Vendor bill processing – Managed by NetSuite role “A/P Specialist”, approved by “A/P Approver”
3. Vendor payment processing – Managed by NetSuite role “A/P Specialist”, approved by “A/P Manager”

In this example, a user has the permissions to create both vendor bills and corresponding vendor payments, which is generally considered a conflict, however this risk is mitigated by the fact that both vendor bills and vendor payments are reviewed/approved by users with separate user roles.

Ultimately, each business will have their own resource constraints and some key functions may need to be managed by the same team where it would be ideal to separate those functions across multiple teams. For smaller businesses this is more of a challenge, so should consider risk mitigating controls such as simple approval processes to ensure that NetSuite records are approved by at least one other person. An alternative would be to manage via saved searches/reminders to flag potential risks. For larger businesses, they may want to consider a more formal NetSuite user role SOD audit to review potential conflicts and address those issues. Subsequently, the user roles would be locked down to avoid the risk of creating future conflicts.
‍

Migrating NetSuite user roles between accounts

In the past, NetSuite user roles have sometimes posed a challenge for NetSuite administrators looking to migrate user roles natively from one environment to another. For example, consider a company performing a full SOD audit. The first step would be to perform a NetSuite sandbox refresh, followed by making all the necessary role permission changes in their NetSuite sandbox account to validate the proposed changes will not break any business processes. That same company then wishes to accurately migrate all those changes to Production in a timely manner. Depending upon the number of user roles and the volume of role permission changes, this could prove to be a monumental task if performed manually in the NetSuite UI. 

While this manual approach does get the job done, leveraging a tool such as Salto, which will validate user role permission differences across NetSuite environments and deploy the required changes seamlessly, helps to mitigate the risk of human error and can make your NetSuite experience flow even more smoothly.

‍

Global Permissions

NetSuite global permissions is a feature that can be enabled in your account.

Navigate: Setup > Company > Enable Features > Employees > Permissions > Global Permissions

When this feature is enabled, you will have the ability to assign user role permissions on the employee record itself. These permissions will then apply to that user for any role they use in that NetSuite environment.  

While this feature can be helpful, especially in situations where you might need to temporarily grant a user access to a specific function to cover when someone is out on vacation, it is generally recommended that global permissions are not used. In that same scenario you should temporarily grant access to the user role itself that will allow the user to cover for the person on vacation, unless it would result in direct SOD conflicts that need to be avoided.

In short, try not to use this feature even if it has been enabled in your NetSuite account. If you do find yourself using it, do so sparingly and ideally for temporary needs only.

‍

Final thoughts

When configuring NetSuite roles and permissions always keep in mind the ‘principle of least privilege’. There are almost an unlimited combination of role permission and permission levels for any given user role, so strongly consider aligning permissions for like roles and think about ongoing maintenance when creating new roles and assigning forms to specific roles. Consider your options before performing a large NetSuite user role migration from one account to another. There are alternatives to doing this manually, role by role, permission by permission.