A clear and confident understanding of user roles is vital to successfully managing NetSuite. Whether you are implementing a new account, cleaning up an old one or setting up segregation of duties for SOX compliance, you need to have a firm grasp of a few fundamentals.
Understanding User Roles
NetSuite has a role-based access control system. This means that each user needs a role assigned to them in order to get access, and that role governs what they can see and do in the system.
There are 636 distinct permissions governing 4923 separate tasks, searches and records. In addition, each role can have a preferred or required list view or form for every record and transaction type. And on top of that are all of the contextual settings that govern what data a user sees from different segments and subsidiaries. Depending on the nature of your account, that could be hundreds of thousands of potential combinations.
However, the reality is rarely that complex. In simple terms, roles are made of three things:
- Permissions: give users the right to see data and do things with it.
- Restrictions: limits the use of a permission to data relating to your subsidiary, department or class.
- Interfaces: such as forms, list views and dashboards, and the overall navigation theme known as a ‘center,’ define how users see things.
Understanding User Permissions
Each user role (except Administrator) needs at least one permission. Essentially, a permission is a bundle of rights that govern what a user can and can’t do in the system.
Most permissions also have a range of permission levels, from View to Full. They are:
- View: The user can see the data but cannot change it
- Create: The user can ALSO create a record or transaction, but cannot edit it
- Edit: The user can ALSO change a record or transaction after it was created
- Full: The user can ALSO DELETE a record or transaction
Be very, very careful about granting Full permission levels to almost anyone, for almost anything. Almost no operational roles should have any transactional permission set at Full.
Four FAQs About User Permissions
What permissions does the Admin role have?
Administrators have all permissions AND the ability to grant access to anyone AND the ability to delete your entire account. So you should be very careful about who you give Admin access to. One key thing that needs to be remembered is that almost all the capabilities included in the Administrator role are available as separate permissions. The best way to think about a permission is as a shortcut that enables Administrators to give a role a group of capabilities in one step.
What is a task?
Many permissions are described in relation to a task. This relationship is one of the main sources of confusion around permissions. So what is a task?
A task is basically a path to doing something in NetSuite. It is always represented by one or more interface elements. These elements may be something in the navigation or in a record or transaction interface.
For example, the Sales Order Approval permission turns on and off the Sales Order Approval task. Without this permission, a user cannot approve a sales order.
The “View” permission level controls the navigation and, in some cases, the ability to add a reminder to a dashboard. The other levels control the ability to create, change or delete data in records, transactions or settings, which in turn may change the functionality of an interface by adding a button or enabling an approval status.
This is true not just of data and transactions, but also of all of the configuration permissions noted above. Additionally, it doesn’t really matter whether the capability is called a task or a record — the functional relationship to the permission is the same.
What are the different categories for NetSuite roles and permissions?
- Transactions: These permissions control access to NetSuite transaction records and the ability to approve them. It’s important to assign limited permissions based on specific roles to ensure proper segregation of duties. Consider whether certain roles require permissions for configuring SuiteFlow workflows related to transactions.
- Reports: These permissions determine access to broader financial reporting within NetSuite. Roles involved in financial reporting typically have most of these permissions assigned to them.
- Lists: This category covers access to all non-transaction records in NetSuite, such as customers, vendors, and employees. Keep in mind that not all permissions in this category may be intuitively named, so carefully review each permission to understand its purpose. Certain administrative permissions, like “Mass Updates,” should be restricted to a small subset of users.
- Setup: These permissions are mostly administrative in nature. However, some permissions in this category may be relevant for a broader range of roles. For example, the “Import CSV File” permission allows end users to process their own CSV imports for records they have access to. Additionally, the “SAML Single Sign-on” permission is essential for roles using single sign-on authentication.
- Custom Record: This category pertains to SuiteApps or custom records within NetSuite. Access to specific records or groups of records can be granted to users based on their roles. During the implementation of a new SuiteApp, these permissions are often adjusted to allow users to interact with the solution as needed.
Monitoring Admin Behavior
In NetSuite, the Administrator role gives users broad transactional powers — and with that comes the potential for fraud. In an ideal world, no one user would be able to create, edit and delete transactions in a production account.
Regularly monitoring and reviewing all transactional changes made by users with admin privileges is a key part of prepping for SOX compliance — not to mention a best practice for staying safe. However, detecting these changes is more difficult than you might expect. As a result, even if you trust your team completely, audit readiness can be a challenge.
The root of the problem is that in NetSuite, some scripts and workflows will execute as an administrator, even if they’re not triggered by a user with admin privileges. The result is hundreds or even thousands of false positives when you run a search of system notes for transactional activity.
Cleaning Up Unused Roles
Access management in NetSuite is much more difficult when you have unused roles in your system. Like other forms of technical debt, used roles make every decision about access control more difficult. And the longer you put off a cleanup project, the worse the problem gets.
Two types of roles are candidates for cleanup:
- Unassigned roles that are not assigned to anyone
- Unused roles that are assigned but not in use
To find unassigned roles, simply run a search of the employee record and group the results by role. Any user role that isn’t on the list is not assigned to anyone.
To find unused roles, run a search of the Login Audit Trail (Setup>Manage Users>View User Login Audit Trail) for all logins in the last six months. If the role is not on this list, it is not in use.
In a busy account, these searches may time out. To work around the problem, narrow your search to just the roles you are concerned about.
Why It’s Easier with Netwrix Strongpoint
Netwrix Strongpoint comes bundled with out-of-the-box searches for identifying unused and unassigned roles in NetSuite.
Netwrix Strongpoint provides an extra level of security and peace of mind, automatically storing deleted roles in a permanent archive that can be restored at any time.
As we mentioned above, Netwrix Strongpoint is the only solution that finds scripts that execute as a specific role.
Reviewing Permission Usage
Every time a record is edited, NetSuite creates a system note that describes what was changed, when it changed, by whom and by what role. Using this, we can work backwards to find out what permissions are being used to change data.
If the record has system notes, and there are no system notes relating to users creating or editing the relevant record, the permission is not being actively used (ie, it is not being used to enter or change data/settings).
However, a permission that is not actively being used may include navigation elements that aren’t captured in system notes. So if you’re using this method to clean up NetSuite permissions, any candidates you identify should be set to View — not deleted — to prevent navigation issues.
Finally, if you find you need to set a permission to View (or to remove a permission) from a group of custom roles, you can make that change using a mass update. However, be VERY CAREFUL that you are selecting the correct roles.
Key Netwrix Strongpoint Reports:
Netwrix Strongpoint comes with three out-of-the-box reports to help you review permission usage:
- Transactional Activity by Role: The ‘Transactional activity by role’ report covers all transactions, including custom transactions
- Company Activity by Role: The ‘Company activity by role’ report covers Leads, Customers, Prospects, Vendors, Partners and Other Companies
- Other Record Activity by Role: The ‘Other record activity by role’ report covers all records and settings that have system notes
Applying the Principle of Least Privilege to NetSuite
To ensure data security and minimize the risk of unauthorized access, it is crucial to apply the principle of least privilege when configuring user privileges and roles within NetSuite. By granting users the minimum privileges necessary to perform their job functions, organizations can reduce the potential for abuse and unauthorized actions within the system.
The principle of least privilege advocates granting users the least amount of privilege required for them to perform their job responsibilities effectively. It discourages the practice of assigning excessive privileges or roles, particularly during the early stages of an organization when speed and agility are emphasized. Granting unnecessary privileges can leave the system vulnerable to abuse and compromise security. Regular review of user privileges is essential to ensure they align with current job responsibilities.
When configuring user privileges and roles in NetSuite, it is crucial to adhere to the principle of least privilege to maintain a secure environment. Here are some key considerations:
- Role-based Permissions: Align permissions for similar roles to ensure consistency and ease of ongoing maintenance. By grouping users with similar job functions under appropriate roles, you can streamline the assignment of permissions and reduce the risk of granting excessive access.
- Thoughtful Role Creation: When creating new roles, carefully assess the required permissions for each role. Consider the principle of least privilege and assign only the necessary privileges based on the specific job functions of the users within those roles.
- Ongoing Maintenance: Regularly review and update user privileges and roles as job responsibilities change. This practice helps ensure that users have the necessary privileges to perform their tasks effectively without unnecessary access to sensitive data or system functions.
- Controlled Migration of User Roles: When performing large-scale user role migrations within NetSuite, consider alternatives to manual migration. Evaluate options that enable efficient and secure role transitions while minimizing the potential for errors or unintended privilege escalations.
Business Process Risks: Ensuring Correct NetSuite Permissions
Assigning role permissions and permission levels in NetSuite is crucial for controlling user access and maintaining system security. However, granting incorrect permissions or inappropriate levels can introduce business process risks. For example, excessive permissions without proper controls can lead to fraud or errors, while inadequate permissions may hinder critical tasks like financial closing processes. By carefully evaluating and aligning role permissions with the principle of least privilege, organizations can mitigate risks and ensure a secure NetSuite environment.
NetSuite offers various types of restrictions that can be defined within roles to control access to different types of records. These include Employee Restrictions, Department Restrictions, Class Restrictions, Location Restrictions, and Subsidiary Restrictions. Each restriction limits access to specific record types based on certain field values, ensuring that users with assigned roles can only view or edit relevant records.
However, when permissions and permission levels are not assigned correctly, there are potential business process risks. Granting excessive permissions, such as allowing a user role to create vendor records, vendor bills, and vendor payments without appropriate controls, can introduce significant risks to the organization. It is crucial to evaluate and implement necessary risk mitigation measures to avoid potential fraud or errors.
Managing Segregation of Duties in NetSuite
Segregation of duties is the concept that the same person should not be able to complete subsequent steps on the same chain of transactions. For example, a person who could write checks and also balance the bank account could cover their tracks in a fraud.
Segregation of duties is obvious a big concern when reviewing NetSuite roles and permissions. It’s a critical part of SOX compliance, and it’s also increasingly called for in private companies.
Standard practice for maintaining segregation of duties is to divide responsibilities between different people with different roles. It can also be achieved by adding a control step, such as a secondary review or approval, on one part of a transaction.
The biggest mistake companies make when implementing SoD is that they don’t clean up their user roles first. The second biggest mistake is that they get too tied up cleaning up their roles. With that in mind, we can chart a much simpler path to get live with SoD:
- Find and deactivate all unused and unassigned roles
- Find and remove all unused role assignments
- Check for SoD conflicts within roles using Netwrix Strongpoint’s rules library
- Check if the conflicting permissions are being actively used; if not, set them to “View” to resolve the conflict.
- Resolve any remaining conflicts by building smart controls using Netwrix Strongpoint Agent.
- Check for multi-role conflicts and resolve them using Agent.
Segregation of duties (SoD) is crucial for maintaining effective internal controls and preventing errors and fraud within an organization. There are three main areas that need to be segregated: authorization, safekeeping, and record-keeping.
By implementing segregation of duties, the risk of fraud is mitigated. Fraud typically occurs when three conditions are present: motive, rationalization, and opportunity. By separating key tasks, such as creating vendors and paying bills, creating customers and issuing credit memos, or creating journal entries and approving them, the opportunity for fraud is reduced.
Segregation of duties is important because it prevents any one person from having excessive control and the ability to misuse that control for unauthorized purposes. It helps protect against fraudulent activities like fund embezzlement, corporate espionage, revenge campaigns, or financial record falsification.
In the context of NetSuite, managing access and enforcing segregation of duties can be complex due to the multitude of permissions and tasks involved. NetSuite contains numerous permissions governing various tasks, searches, and records. Effective management of access requires time and resources that may not always be readily available to administrators and finance teams. Additionally, automation can introduce unexpected conflicts that auditors may view as control deficiencies, making it even more challenging to maintain proper segregation of duties.
SOX Compliance and Access Controls
As mentioned above, SoD — and access review in general — is a big part of SOX compliance. Auditors want to see that fraud prevention controls are built into the system and supported by well-defined roles and permission assignments.
The problem is that traditional SoD access reviews are snapshots in time. NetSuite teams prepare their roles and permissions for quarterly review, often at great expense. This approach requires extensive manual review of related changes and hours of work investigating false positives. As well, it doesn’t give you — or your auditors — any confidence that conflicts occurring between audits will be caught and addressed.
The result is that audit costs balloon, stress levels are high and material deficiencies which further compound both issues are common. What’s more, there’s no real protection built into the system, so even if you can struggle through an audit you’re not really protected against fraud, which is the point of SOX to begin with.
The Continuous Compliance Approach to Access Management
Netwrix Strongpoint is the only native SoD solution for NetSuite. Based on our ‘continuous compliance’ approach to SOX, it monitors roles and permission changes on an ongoing basis, giving you an audit-ready look at access, at any time.
Netwrix Strongpoint can also block particularly unsafe changes, such as granting Admin rights without prior approval. It implements quickly, so you can get up and running with less stress.
Pre-built libraries of rules and tools integrate into the employee record give you the ability to quickly implement detective, blocking and mitigating controls that help control access to critical roles and permissions — and prove it to auditors.
.png)