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.
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.
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:
- Vendor record creation – Managed by NetSuite role “Vendor Manager”
- Vendor bill processing – Managed by NetSuite role “A/P Specialist”, approved by “A/P Approver”
- 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.
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.
