Salto for
NetSuite
Articles
SHARE
Sonny Spencer, BFP, ACA
January 31, 2025
15
min read
While segregation of duties (SOD) is not a strict legal requirement for private companies in the same way as it is for public companies (driven by Sarbanes Oxley - SOX), it is still highly recommended and considered a best practice to be adopted for private companies of all sizes.
By implementing SOD, even if a scaled-down version, private companies are able to mitigate the risk of fraud and errors.
In this article we are going to review some of the best practices to consider when managing SOD in your NetSuite environment.
As we have already discussed, it is important for any company leveraging NetSuite to think through whether they have the appropriate controls in place as it relates to SOD.
When implementing NetSuite for the first time, it is easy to default to leveraging the out of the box user roles. It is always recommended to make copies of these roles, so that they can be tailored to your specific business needs, but it is not so common to design a completely new stack of user roles right from the get go. Additional design and configuration time can add to the cost of an implementation, but it’s best to get this right first time vs redesigning at some point down the road.
Let’s take the procure to pay (P2P) process as an example. By default you could have an end user with the ability to create new vendor records, populate bank details, create vendor bills and process payments. Hopefully some soft alarm bells are going off as you read this. Regardless of the size of a company, you do not want any one person to have the ability to perform each of those tasks. Leveraging approval workflows as mitigating controls is definitely an option, but there are alternatives to consider.
Taking each of those steps, would it not be better to separate those P2P processes into multiple NetSuite user roles? Consider this simple structure:
By segregating some of the key steps in the P2P process and with some additional compensating controls, such as a vendor bill approval workflow, we can significantly reduce the risk of SOD conflicts.
In summary, don’t be afraid to create new user roles in NetSuite that differ from those available out of the box. Just don’t create too many so that it becomes unmanageable to maintain them all.
If you simply copied the out of the box user roles in NetSuite you would have many users with the ability to delete records in the system. Some user role permissions only have the permission level FULL available for selection, but most have VIEW, CREATE and EDIT as alternative options. Any time you are reviewing a user role and see the word FULL it should give you pause and ask yourself if this user should have the ability to delete the related record type. If the answer is no, you should reduce the permission level from FULL to EDIT (or lower depending upon the use case).
Also consider that some user role permissions grant dual or multiple capabilities in NetSuite. A great example of this is the “Currency” permission. If you need a user role to have the ability to modify exchange rates on transaction records you need to set this permission level to EDIT. In doing so, whether knowingly or not (now you do know), you have now granted users with that same role the ability to create new currencies in your NetSuite environment.
Regardless of the permission and permission level, always default to the principle of least privilege. This involves making sure your end users have the absolute minimum level of system access needed to perform their daily duties in NetSuite and nothing more.
SOD conflicts cannot always be avoided through the customization of user roles and permissions alone. Some permissions inherently grant users the ability to create and approve their own system entries. For use cases such as these it is important to establish appropriate compensating controls. A great example is an approval workflow.
Users may have user roles and permissions that would allow them to create and approve their own journal entries, however by leveraging SuiteFlow you can add criteria logic that ensures users cannot approve the journal entry if they created it themself. This extends beyond journal entries and beyond approval workflows.
Where possible, leverage system functionality to support these compensating controls vs relying upon manual reviews. By nature these are manual and time consuming, so leverage your highly customizable ERP to make this an integral part of the process to enforce the right behavior vs trying to correct it after the fact.
NetSuite continues to innovate across all key areas of the platform. Let’s explore some of the latest enhancements to these features in 2024.
While there are no SOD specific features rolled out in the 2024 NetSuite releases, there were some related updates in the form of new standard user roles that have been made available.
For example in the most recent release (2024.2), a new “CRM Role” was introduced to allow users to manage sales, CPQ, marketing, support and all other related CRM activities. This includes working with Opportunities, Quotes, Sales Orders and other customer-facing records. This is a great starting point (to be customized) for smaller companies that have hybrid roles spanning the end to end CPQ process.
Another role that was made available is the “View and Approve Role” which grants a limited view into NetSuite. Specifically, users can perform tasks like viewing and approving reports, but generally prevented from completing more involved tasks. Similar to an employee center role in that sense. A good use case for this starting point (again to be customized) is for managers who need to review their team’s performance and also approve purchase requests in the system, but nothing else.
For more details on the 2024 NetSuite Releases, here are the links to the 2024 NetSuite Release Notes for quick reference.
SOD customizations in NetSuite typically come in the form of custom user roles and permissions, although compensating controls can take on many forms - perhaps the most common being an approval workflow that leverages SuiteFlow.
We will explore the challenges of migrating NetSuite customizations manually through the lens of user roles and permissions, which are the backbone for operating with appropriate SOD controls in place.
Attempting to migrate custom user roles and permissions manually can take a very long time, especially if performing a more significant overhaul of user roles. The risk of human error is high, given the sheer volume of configuration options, hundreds of list values to populate and multi-select field values to set. Validating each and every value can be excruciatingly painful. No NetSuite Administrator wants to do that.
Many NetSuite customers, especially those preparing for IPO, will perform a complete SOD review of their existing user roles to identify potential conflicts. This process in itself takes a long time to complete, but ultimately leads to strong controls - time well invested.
Now imagine you have to migrate all of the new user roles as well as modifications to existing roles from your Sandbox account to your Production account. This process is not value add and given the expected volume of changes, the risk of human error is very HIGH.
Check out the cost of getting deployments wrong (with a calculator) here.
Now, let’s explore solutions to these challenges.
Given the risk of error with migrating large volumes of changes in NetSuite from one environment to another, NetSuite Administrators need to rely upon more system solutions to manage the migration process. This is especially important for migrating user roles and permissions, as the risk of getting a single configuration value wrong is very high and depending upon the error could completely undo the significant effort that went into modifying the user roles in the first place.
NetSuite has a number of native solutions that are available to Administrators, such as Copy to Account, SuiteBundler and SuiteCloud Development Framework (SDF). Each of these solutions has its own advantages and disadvantages to using them, so Administrators should review each of these tools to see which would be the most effective for migrating your user role customizations across different NetSuite environments.
If you are working across multiple NetSuite environments with active development and customization then there are alternative solutions to consider. One alternative NetSuite Administrators are looking at is Salto - check out the Salto SuiteApp. The Salto platform allows NetSuite Administrators to perform direct environment comparisons to easily identify any potential deployment conflicts.
When working with user roles and permissions in particular, you may run into deployment conflicts where custom records have been created in one environment, but not another. This can result in deployment conflicts that have to be resolved before your customizations can be available in Production.
In addition to streamlining the deployment process, Salto allows NetSuite Administrators the ability to quickly execute system rollbacks in the case of customizations being deployment that don’t have the desired impact in the Production environment. The need to perform a rollback should be uncommon, however when needed they often need to be expedited.
Now that you have successfully deployed your NetSuite user roles and related permissions to Production, let’s consider some best practices specific to SOD.
Salto Tip: Check out this FREE NetSuite Administrator training course on Salto Leap to see how you can become a Master NetSuite Administrator and NetSuite guru for your company.
For more Best Practices to manage your NetSuite customizations, check out Salto’s blog posts that explore some of the things that NetSuite Developers and NetSuite Administrators should be leveraging within the NetSuite ecosystem.
SOD is not going to be a top priority for every private company operating NetSuite today, but it should be a priority nonetheless. Mitigating the risk of fraud and error in key business processes should always be top of mind. Smaller companies may need their end users to wear multiple hats and that is OK, as long as they have appropriate checks and balances (mitigating controls) in place.
It is never too early to start thinking about how you can leverage NetSuite user roles and permissions to establish a SOD framework that will scale with the business. If you haven’t started your SOD journey already, then what are you waiting for?
Salto for
NetSuite
NetSuite
SHARE
Sonny Spencer, BFP, ACA
January 31, 2025
15
min read
While segregation of duties (SOD) is not a strict legal requirement for private companies in the same way as it is for public companies (driven by Sarbanes Oxley - SOX), it is still highly recommended and considered a best practice to be adopted for private companies of all sizes.
By implementing SOD, even if a scaled-down version, private companies are able to mitigate the risk of fraud and errors.
In this article we are going to review some of the best practices to consider when managing SOD in your NetSuite environment.
As we have already discussed, it is important for any company leveraging NetSuite to think through whether they have the appropriate controls in place as it relates to SOD.
When implementing NetSuite for the first time, it is easy to default to leveraging the out of the box user roles. It is always recommended to make copies of these roles, so that they can be tailored to your specific business needs, but it is not so common to design a completely new stack of user roles right from the get go. Additional design and configuration time can add to the cost of an implementation, but it’s best to get this right first time vs redesigning at some point down the road.
Let’s take the procure to pay (P2P) process as an example. By default you could have an end user with the ability to create new vendor records, populate bank details, create vendor bills and process payments. Hopefully some soft alarm bells are going off as you read this. Regardless of the size of a company, you do not want any one person to have the ability to perform each of those tasks. Leveraging approval workflows as mitigating controls is definitely an option, but there are alternatives to consider.
Taking each of those steps, would it not be better to separate those P2P processes into multiple NetSuite user roles? Consider this simple structure:
By segregating some of the key steps in the P2P process and with some additional compensating controls, such as a vendor bill approval workflow, we can significantly reduce the risk of SOD conflicts.
In summary, don’t be afraid to create new user roles in NetSuite that differ from those available out of the box. Just don’t create too many so that it becomes unmanageable to maintain them all.
If you simply copied the out of the box user roles in NetSuite you would have many users with the ability to delete records in the system. Some user role permissions only have the permission level FULL available for selection, but most have VIEW, CREATE and EDIT as alternative options. Any time you are reviewing a user role and see the word FULL it should give you pause and ask yourself if this user should have the ability to delete the related record type. If the answer is no, you should reduce the permission level from FULL to EDIT (or lower depending upon the use case).
Also consider that some user role permissions grant dual or multiple capabilities in NetSuite. A great example of this is the “Currency” permission. If you need a user role to have the ability to modify exchange rates on transaction records you need to set this permission level to EDIT. In doing so, whether knowingly or not (now you do know), you have now granted users with that same role the ability to create new currencies in your NetSuite environment.
Regardless of the permission and permission level, always default to the principle of least privilege. This involves making sure your end users have the absolute minimum level of system access needed to perform their daily duties in NetSuite and nothing more.
SOD conflicts cannot always be avoided through the customization of user roles and permissions alone. Some permissions inherently grant users the ability to create and approve their own system entries. For use cases such as these it is important to establish appropriate compensating controls. A great example is an approval workflow.
Users may have user roles and permissions that would allow them to create and approve their own journal entries, however by leveraging SuiteFlow you can add criteria logic that ensures users cannot approve the journal entry if they created it themself. This extends beyond journal entries and beyond approval workflows.
Where possible, leverage system functionality to support these compensating controls vs relying upon manual reviews. By nature these are manual and time consuming, so leverage your highly customizable ERP to make this an integral part of the process to enforce the right behavior vs trying to correct it after the fact.
NetSuite continues to innovate across all key areas of the platform. Let’s explore some of the latest enhancements to these features in 2024.
While there are no SOD specific features rolled out in the 2024 NetSuite releases, there were some related updates in the form of new standard user roles that have been made available.
For example in the most recent release (2024.2), a new “CRM Role” was introduced to allow users to manage sales, CPQ, marketing, support and all other related CRM activities. This includes working with Opportunities, Quotes, Sales Orders and other customer-facing records. This is a great starting point (to be customized) for smaller companies that have hybrid roles spanning the end to end CPQ process.
Another role that was made available is the “View and Approve Role” which grants a limited view into NetSuite. Specifically, users can perform tasks like viewing and approving reports, but generally prevented from completing more involved tasks. Similar to an employee center role in that sense. A good use case for this starting point (again to be customized) is for managers who need to review their team’s performance and also approve purchase requests in the system, but nothing else.
For more details on the 2024 NetSuite Releases, here are the links to the 2024 NetSuite Release Notes for quick reference.
SOD customizations in NetSuite typically come in the form of custom user roles and permissions, although compensating controls can take on many forms - perhaps the most common being an approval workflow that leverages SuiteFlow.
We will explore the challenges of migrating NetSuite customizations manually through the lens of user roles and permissions, which are the backbone for operating with appropriate SOD controls in place.
Attempting to migrate custom user roles and permissions manually can take a very long time, especially if performing a more significant overhaul of user roles. The risk of human error is high, given the sheer volume of configuration options, hundreds of list values to populate and multi-select field values to set. Validating each and every value can be excruciatingly painful. No NetSuite Administrator wants to do that.
Many NetSuite customers, especially those preparing for IPO, will perform a complete SOD review of their existing user roles to identify potential conflicts. This process in itself takes a long time to complete, but ultimately leads to strong controls - time well invested.
Now imagine you have to migrate all of the new user roles as well as modifications to existing roles from your Sandbox account to your Production account. This process is not value add and given the expected volume of changes, the risk of human error is very HIGH.
Check out the cost of getting deployments wrong (with a calculator) here.
Now, let’s explore solutions to these challenges.
Given the risk of error with migrating large volumes of changes in NetSuite from one environment to another, NetSuite Administrators need to rely upon more system solutions to manage the migration process. This is especially important for migrating user roles and permissions, as the risk of getting a single configuration value wrong is very high and depending upon the error could completely undo the significant effort that went into modifying the user roles in the first place.
NetSuite has a number of native solutions that are available to Administrators, such as Copy to Account, SuiteBundler and SuiteCloud Development Framework (SDF). Each of these solutions has its own advantages and disadvantages to using them, so Administrators should review each of these tools to see which would be the most effective for migrating your user role customizations across different NetSuite environments.
If you are working across multiple NetSuite environments with active development and customization then there are alternative solutions to consider. One alternative NetSuite Administrators are looking at is Salto - check out the Salto SuiteApp. The Salto platform allows NetSuite Administrators to perform direct environment comparisons to easily identify any potential deployment conflicts.
When working with user roles and permissions in particular, you may run into deployment conflicts where custom records have been created in one environment, but not another. This can result in deployment conflicts that have to be resolved before your customizations can be available in Production.
In addition to streamlining the deployment process, Salto allows NetSuite Administrators the ability to quickly execute system rollbacks in the case of customizations being deployment that don’t have the desired impact in the Production environment. The need to perform a rollback should be uncommon, however when needed they often need to be expedited.
Now that you have successfully deployed your NetSuite user roles and related permissions to Production, let’s consider some best practices specific to SOD.
Salto Tip: Check out this FREE NetSuite Administrator training course on Salto Leap to see how you can become a Master NetSuite Administrator and NetSuite guru for your company.
For more Best Practices to manage your NetSuite customizations, check out Salto’s blog posts that explore some of the things that NetSuite Developers and NetSuite Administrators should be leveraging within the NetSuite ecosystem.
SOD is not going to be a top priority for every private company operating NetSuite today, but it should be a priority nonetheless. Mitigating the risk of fraud and error in key business processes should always be top of mind. Smaller companies may need their end users to wear multiple hats and that is OK, as long as they have appropriate checks and balances (mitigating controls) in place.
It is never too early to start thinking about how you can leverage NetSuite user roles and permissions to establish a SOD framework that will scale with the business. If you haven’t started your SOD journey already, then what are you waiting for?