Salto for
NetSuite
Articles
SHARE
Sonny Spencer, BFP, ACA
September 19, 2022
10
min read
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.
STAY UP TO DATE
If we ever spam you, unsubscribe instantly (& spam us back - arik.marmorstein@salto.io)
Don’t miss NetSuite content that will make you better at your work
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.
There are many configuration options when customizing a NetSuite role. This guide will walk you through some of these key configuration options.
General Configuration
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.
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:
NetSuite separates the role permissions into five broader categories:
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.
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.
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:
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.
STAY UP TO DATE
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.
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.
Salto for
NetSuite
NetSuite
SHARE
Sonny Spencer, BFP, ACA
September 19, 2022
10
min read
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.
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.
There are many configuration options when customizing a NetSuite role. This guide will walk you through some of these key configuration options.
General Configuration
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.
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:
NetSuite separates the role permissions into five broader categories:
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.
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.
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:
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.
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.
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.