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

‍

Introduction

Getting your NetSuite user roles and permissions right is essential for optimal end user experience and security of your system. Despite this, NetSuite Administrators still make a number of common mistakes when establishing and maintaining them. In this article we will explore many of the common mistakes made when working with NetSuite user roles and permissions, as well as share some best practices that you can apply right away.

‍

‍

Mistake 1 - Defaulting to “Full” permission level

Many out of the box user roles have the “Full” permission level assigned to many permissions, and NetSuite Administrators will typically make a copy of one of these roles as a starting point for creating new custom roles.

This is typically the approach taken, so it is important to review each of these permissions carefully to ensure that “Full” permission level is granted only when absolutely necessary. Some role permissions only allow that permission level (e.g. Import > Import CSV File), whereas others allow for varying levels of user access: View / Create / Edit / Full. In these cases, users with a permission level set to “Full” have the ability to delete records and reports associated with that particular role permission.

Generally, you should limit the ability for end users to delete records in NetSuite, which is why granting the “Full” permission should be done on an as needed basis. Instead, role permissions should be granted with the “principle of least privilege” in mind, thereby only granting user access to exactly what a particular user requires—nothing more, nothing less.

Salto Tip: Run a “Deleted Record Audit Log” for a quick look at which users have been deleting NetSuite records as a starting point for a broader user permission audit.

‍

Mistake 2 - Ignoring custom record permissions

Every NetSuite customer works with custom records on a daily basis, yet the user role permissions for these custom records often get overlooked.

If you utilize custom records in your NetSuite environment to meet the needs of your company you need to ensure that the appropriate permissions have been assigned to all user roles that require access to interact with them. Consider the permission level for each role; perhaps some roles should be able to view these custom records, whereas others may need the ability to modify these custom records.

Even if you have not created a custom record of your own it is still very likely that your NetSuite environment has custom record permissions to assign. That is because NetSuite third party solutions allow for the installation of their software package via SuiteBundler or the SuiteApp Marketplace. Once installed, a number of custom record permissions will be automatically added to your account to allow your users to engage with the new solution. Some examples include the NetSuite Fixed Asset Management (FAM) bundle and Electronic Bank Payments bundle.

Salto Tip: If a user is struggling to interact with a third party NetSuite solution, a good place to start is to review their user role permissions and focus on their “Custom Record” role permissions to see if any key permissions are missing or not at the required level.

‍

Mistake 3 - Not considering segregation of duties

In Mistake 1, we discussed some of the challenges with out of the box user roles in relation to permission levels. The same can be said for the permissions themselves, which is why it is essential to create custom roles tailored to your business needs.

It is important to consider the various roles that will be required in your NetSuite environment before jumping in and creating them. Think about the different processes and the roles associated with each, e.g. quote to cash, procure to pay and record to report. 

For the procure to pay process area, it is important to establish user roles that ensure an appropriate segregation of duties. You should think about separating the key processes across different user roles: 

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”

This proposed structure may not work for every organization. In fact, for smaller organizations it could result in a number of users having multiple roles. Where it is not possible to manage SOD conflicts solely with user roles, think about compensating controls that can be established to mitigate risks, such as an approval workflow.

Salto Tip: Once an initial user role audit/review has been performed, it is best to lock these roles down to minimize future changes that could inadvertently introduce conflicts.

‍

Mistake 4 - Overlooking custom form restrictions

Leveraging custom forms is a great way to improve the UI experience for your end users. In some cases, you may create several custom forms for the same record type to accommodate regional differences, e.g. multiple sales order forms, one per region. 

You can display the custom form field on the form itself to allow your end users to select the appropriate value for their region or you can automate this process without any custom development. Simply navigate to a role that works with sales orders, then go to Forms > Transaction. Adjacent to the sales order custom form that should be used by this role, first check the box labeled “Preferred”, then check the “Restricted” box. Doing so will force the user to always use this custom form when interacting with that particular record type.

Salto Tip: You may opt to disable the other forms leaving the required form enabled. This is not a good practice because when future custom forms are added for that same record type, the user will (by default) have access to those new custom forms. That is why it is best to utilize the “Restricted” check box.

‍

Mistake 5 - Forgetting to create non-SSO roles for testing

Many organizations are leveraging single sign-on (SSO) to access their internal applications in a secure manner. As a result, a large number of NetSuite users will access NetSuite via SSO as opposed to traditional credentials.

This can be challenging for NetSuite Administrators who are required to use traditional credentials when using the Administrator role, but need to switch to SSO when testing end user roles with deflated permissions sets. 

After refreshing your NetSuite sandbox, take 5-10 minutes to create non-SSO versions of user roles that can be assigned to NetSuite Administrators for testing purposes. Simply navigate to a role, make a copy by using the “Save As” function, then remove the “SAML Single Sign-on” permission (under “Setup”).  Administrators can then assign themselves the non-SSO roles to avoid switching back and forth between SSO and user credentials. This will save time, especially on initiatives that require more robust testing over a period of time.

Salto Tip: When working with third party consultants that need to access your NetSuite environment, you may not be comfortable granting Administrator access. As a result, you will need to assign them a non-SSO role as the consultants will not be able to authenticate via SSO.

‍

Mistake 6 - Not grouping roles by “Role Type”

One way to avoid creating a vast number of unique user roles is to think about the different functions within your organization that require NetSuite access and group them based upon the actions they need to perform in the system.

If you have users in different regions operating the same processes for their respective subsidiaries, it would make sense to “group” these users under a single “Role Type”.  Let us consider an example:

We have a number of users in North America processing vendor bills for subsidiaries in North America and another group of users in EMEA processing vendor bills for subsidiaries in EMEA. The role performed is exactly the same, but permissions are segregated by region.

Role Type = A/P Specialist

Role North America = A/P Specialist (North America)

Role EMEA = A/P Specialist (EMEA)

This is an important distinction because the expectation is that both user roles are identical with the exception of subsidiary access. Then, if we continue to expand internationally, we can make a copy of one of these roles and create an A/P Specialist (APAC) role in the future. Taking this approach to managing your user roles in NetSuite allows for better future proofing. When customizing NetSuite you would reference role types as opposed to groups of similar roles. That way when a future role is added to the same role type (group) there will be no need to revisit past customizations to see if any role-related updates are required, because the customizations already reference the existing role type.

Salto Tip: Consider adding a custom field to the role record type in NetSuite that captures the “Role Type”. This allows for the grouping of roles into different types, which can then be referenced in system configuration.

‍

Mistake 7 - Not creating a role with the right center type

This mistake is pretty straightforward—don’t forget that when creating a new user role you cannot change the center type once you click on “Save”, so make sure this is correct before spending time populating all of the permissions and permission levels.

Along the same lines, when copying an existing role you are forced to use the same center type as the role you copied. In theory, if you require two identical roles under two different center types you will need to create them both separately vs creating one and copying. This should not be a realistic use case, but is still worth noting.

Salto Tip: If you inadvertently created a role with the wrong center type, you can still force the user to work in the “Classic Interface” by applying the “Use Classic Interface” preference on the role. This can be added under the “Preferences” subtab on the role record.

‍

Mistake 8 - Reducing “Currency” permission access from Edit to View

It is true that granting “Edit” level permission to the “Currency” permission allows users to create new currencies in your NetSuite environment. Typically, this is something you would want to restrict to NetSuite Administrators or a subset of users. As a result, some might be quick to jump to the conclusion that reducing the permission level to “View” for most user roles will be the right thing to do. That is rarely the case.

This is because the “Currency” permission serves a number of purposes and is not just tied to the ability to create new (or modify existing) currencies in NetSuite. In fact, “Edit” level permission is required in order to allow users to modify exchange rates on transaction records, so if you want your users to be able to record accurate transactions with the appropriate exchange rates (think about bank account transactions that will use bank rates vs NetSuite rates) then you will need to leave the permission at the “Edit” level.

While this is not ideal, there is no workaround. Fortunately, most users who have this permission/permission level do not know they have the ability to create new currency records in the system.

Salto Tip: As a safety net, consider creating a system note saved search that references the currency record type filtered to the “create” type. This can then be set up as a dashboard reminder for NetSuite Administrators to monitor or sent as a scheduled email if there are any results.

‍

Mistake 9 - Forgetting to leverage “Show Role Differences”

The “Show Role Differences” tool can be very helpful in identifying role permission differences across two or more roles. 

Navigate: Setup > Users/Roles > Show Role Differences

Select the appropriate “Base Role” then one or more in the “Compare To” list. The results will display the Base Role on the left hand side to allow for ease of comparison. The “Only Show Differences” checkbox will be checked by default as it is the most efficient way to identify differences between user role permissions and permission levels. Uncheck if you want to view all role permissions assigned to those roles.

Note that this function does not show all physical differences between user roles. It is focused on the role permissions and corresponding levels. It does not consider subsidiary restrictions, form restrictions, preference overrides, etc.

Salto Tip: If you are looking to perform a larger audit of all NetSuite user roles then consider a full extract. To do this, simply set the “Base Role” to any role and select all of the available roles in the “Compare To” list. Finally, uncheck the “Only Show Differences” check box before clicking on “Show” and exporting to Excel.

‍

Mistake 10 - Migrating user roles manually

Anyone who has manually migrated a user role from one NetSuite environment to another knows this process can be somewhat of a hassle.

User roles can be migrated using a number of NetSuite out of the box options. NetSuite offers a number of options in the form of SuiteBundler, Copy to Account and SuiteCloud Development Framework (SDF). There are pros and cons to each of these methods. If you plan on leveraging SuiteBundler, then be mindful of potential dependencies that NetSuite will pull in if the roles/permissions are intertwined with other NetSuite objects. Also consider that you might need to uninstall/reinstall the bundle if it doesn’t take the first time. Copy to Account is another user-friendly method of migrating user roles, but again, you will need to work through any dependencies that arise, typically sequentially vs all at once. Both SuiteBundler and Copy to Account will be more user-friendly for NetSuite Administrators, whereas developers may prefer to work with SDF.

While these options help to avoid manual migration efforts, another solution to consider is Salto. The Salto SuiteApp helps NetSuite admins and developers manage their NetSuite customizations in a more automated way by speeding up the deployment process, including user roles and permissions. Users have the ability to compare NetSuite environments to help identify any discrepancies between them, as well as confirm record dependencies. There is also the ability to roll back to older versions of NetSuite configuration, which can be a lifesaver when system customization doesn’t have the desired impact.

‍

Best Practices When Working With NetSuite User Roles

1. Apply the principle of least privilege when assigning user role permissions.
2. Review all custom record permissions for each user role to ensure all necessary permissions are granted (or removed).
3. Take the time to understand any potential conflicts in segregation of duties between the custom roles in your NetSuite environment and document user role combinations that should not be granted to a single user.
4. Leverage custom form restrictions to ensure users are interacting with NetSuite in the UI with the forms that allow them to navigate efficiently.
5. After performing a Sandbox refresh, create non-SSO user roles for each SSO user role, which can then be assigned to NetSuite Administrators for testing.
6. Establish user role types and align NetSuite customization to role types instead of specific roles. This is a great way to future proof NetSuite customization that should only be leveraged by a specific group of user roles.
7. Prior to creating a new user role, double check that the center type is accurate, otherwise you run the risk of needing to repeat the process under the correct center type.
8. Double check that all user roles that need the ability to modify transaction exchange rates have “Edit” level permission on the “Currency” role permission.
9. Utilize the “Show Role Differences” screen to export all user roles and permissions to Excel for quick comparison between multiple roles.
10.  With the exception of the “Administrator” and “NetSuite Support Center” roles, never assign NetSuite out of the box roles to users.

For more information on these best practices, check out this blog post that explores some of the things that NetSuite Developers and NetSuite Administrators overlook when working with NetSuite user roles and permissions.

‍

‍

Final thoughts

NetSuite roles and permissions are the keys to the kingdom. Granting access generously can lead to users viewing, or worse, modifying records they should not be privy to. Likewise, restricting access too much can lead to end users not having the ability to perform their day to day tasks in the system. Striking the right balance is essential.

There are many ways to configure a user role in NetSuite. Consider a strategy of creating “role types” wherein you only have 10-20 unique types (same permissions and permission levels) with multiple versions, by region or subsidiary depending upon how your organization is structured.

Regardless of the size of your business, it is important to implement controls centered around segregation of duties and remember to always keep top of mind the “principle of least privilege” when creating and modifying user roles and permissions.