Chapter 5: Analyzing the Organization's Users and Roles
To really know how a business or any other group works, we have to understand who does the work, how they name each person's role in the various teams, and how they work together. Implementing groups of people in NetSuite by function (accounting, warehouse, and so on) is a good start, but you must also understand how they interact and who's in charge.
In this chapter, we will cover the following topics:
- Understanding departments, teams, managers, and users
- Grouping people with roles in NetSuite
- Managing users with multiple roles
With this chapter, you'll learn how to analyze the groups within your client's company, and apply them to roles for use in their NetSuite account.
Important Tip
A quick note here – now we're getting to the content that ties into NetSuite and its various screens. For the remainder of this book, I'll be assuming that you have access to a NetSuite account somehow and so can look at your screens to see how they compare to the images included here. Just remember that, because NetSuite is very customizable and the product is updated twice a year, your screens may not look exactly like mine.
Understanding departments, teams, managers, and users
When we look at any NetSuite client company, we will usually find them organized into departments and each of those will have a manager. This is the bureaucratic approach that came into being a long time ago, but it isn't the only valid model. NetSuite doesn't require any such structure; companies are free to organize themselves into whatever groups make the most sense to them and NetSuite can be adjusted as needed.
Having said that, we do try to start each implementation with the best practices in mind, and we know that most companies are organized into groups. Here are a few examples to help you understand how this usually works.
Accounting
This includes bookkeepers, accountants, and their managers. These people will need access to accounting lists (payment methods, price levels, and so on) and tax records, and they need to be able to work with journal entries and bank records, among other things.
Accounts payable
This group usually includes accounts payable (A/P) clerks and their management. They are the hands-on users of purchase requests and orders, vendor bills, and credits. We usually need at least one role for the front-line users and one more for approvers of the transactions they create (this is a very common request among many groups, in fact).
Accounts receivable
These order to cash folks process cash sales and sales orders. They also need access to create bills (invoices) and statements for their customers. Like any group, we can define them as working with just one subsidiary or department, or multiples whenever needed.
Administrators/upper management
This group includes NetSuite administrators, the CEO, the CIO, and so on. Administrators need to be able to tweak and re-configure most of the NetSuite account when necessary. The CEO and other upper management roles are usually granted read-only access to most transactions and other data, so they can review the business but cannot usually edit others' work.
Information technology
The IT people in most organizations need to be able to monitor others' activity, configure things such as customizations and integrations, and manage imports for things such as items. They are usually not allowed to edit transactions, but they might need permission to provide this kind of oversight in some cases. This group usually includes developers and sometimes testers as well.
Sales
This is the group for inside and outside sales reps, their managers, and upper managers too. We usually see these folks divided up by region or other market definitions (such as product lines or customer groups). Their managers need to be able to review and approve and report on their transactions.
Support
The people who provide support within the company will vary depending on the business. These are usually customer support agents of some sort (who might also sell the the knowledge base. They sometimes also need to edit orders and other transactions as well.
Warehouse
Assuming the client has folks who work in a warehouse of some sort, they will usually need their own roles to allow them to receive items as they arrive and fulfill them as they are shipped out. You might want to configure roles for warehouse managers as well, in cases where you want to restrict some users from the ability to edit these transactions, or to allow managers to provide for approvals before warehouse operations can be completed.
As always, your job will be to amend this list to make sense for each of your clients, and to determine how best to adjust everything in NetSuite to suit their business needs. We start to do that next with roles, which allows us to define grouped permissions, dashboards, and more.
Grouping people with roles in NetSuite
Our goal in understanding a client's people and organization is to allow us to divide them up into roles in their NetSuite account, and then assign permissions to those roles. Since security is a critical element of running your business in a cloud application, we want to make sure that each user with a login to any NetSuite interface has only the permissions they need and no more.
We can model pretty much any business structure we need in NetSuite, via the feature known as roles. Roles in the application have permissions and also establish a set of preferences and default views, and we use them to avoid configuring the account specifically for any individual. In other words, even if you know there is just one person who will have a set of permissions and preferences, it's best to set up a role for them.
The groups shown in the previous section are typical, but again, we're not forced to use them in NetSuite. We always start configuring roles in NetSuite using a set of pre-defined entries. We make copies of those when we have just small changes to make to the default role, or we can instead start a new role from scratch and completely define the set of NetSuite features it will have access to, as we need.
Since it's much faster to start with the NetSuite-provided roles, it will help you to know what they are and how they're meant to be used. Take the time now to review this in a NetSuite account you have access to and you'll see they closely mirror the groups mentioned earlier. So, depending on the company's needs, these default roles can be customized, and that's what we usually do. Refer to the following screenshot:
Figure 5.1 – The Manage Roles screen in NetSuite
We click on the Customize View link on the left (as shown in the preceding screenshot) to create a copy of the default role, and then we can change that any way we need. We name that new role after the company's name, so if they are called ABC Inc., we would name the first role ABC – Accountant. We then repeat that process for every role the company needs to assign to one or more people and get used to managing their permissions and other settings via the role, versus the individual employee's permissions.
When we start out working with a client, we don't spend a lot of time setting up and fine-tuning roles, permissions, and so on. Our main intent with this activity should be to get the client familiar with how roles work in the product and to assign roles to the first few people who will help get things started. This will allow them to start learning first-hand and to start configuring their own account. That usually means this first group of users will have more permissions than they'll need after going live, but that's OK for these very first people. Just make sure all users are clear on how this will work – also, be sure to switch users over to their proper roles before user acceptance testing (UAT) starts. You definitely need to test the permissions and settings assigned to each role at that time, to avoid confusion or problems that only come to light when the client goes live.
Important Tip
NetSuite includes a default role known as Administrator. This role has access to everything in the account – everything. For this reason, assigning this to all of the initial users is a convenient way to get started and get everyone active in the account as you first start out. But don't do it! This can easily lead to people making changes they should not make, and the users will also get too used to being able to do anything in the account they wish to. And as I said earlier in the previous section, there should only be a very small group of people with the Administrator role in any NetSuite account, and that's true from day one.
Instead, get each user into the role they will have to learn to live with as early as possible. You will quickly learn when and how their roles need to be adjusted, as the project unfolds and they test various features. This approach also shows users that security is important, and gives the people who will be the administrators of the account a chance to learn how to do their jobs. This is a good example of a time where you can teach them to fish, rather than doing configuration work for them.
When it comes to deciding which permissions each role will need, quite a few factors come into play. I have explained them in the sections that follow.
Does the user need to view, create, edit, or fully manage a given record or list?
This will control which permission level you assign to the role. For instance, an A/R clerk might just need to create and edit sales orders, but the A/R manager should also be able to delete a transaction in rare cases.
Which custom records does the role need access to?
When you add custom solutions to the account, either via SuiteApps or other customizations, they frequently include custom record types. These are essentially custom tables of data stored in the account, and it's very common to forget to apply permissions to these tables for each role. For instance, if you create a record type called Case Information and want only some users to be able to access these records via sales orders, you will need to assign permissions for only certain roles to be able to view the records on that screen. We do that via the Permissions tab on the custom record type's definition screen.
Which reports will the role need access to?
Going along with the transaction, list, and custom record permissions, we control access to reports so that users cannot gather the information they wouldn't otherwise be able to read. This allows for some flexibility as well, since we might say that a sales rep needs to see the report showing the total number of new cases this week, month, and year, even if they cannot see the details in the cases beyond their own department.
Roles in NetSuite also have functions beyond permissions. They allow us the following additional configuration options:
- Applying restrictions by segments such as department, class, and location, and custom segments as well
- Setting up preferred forms so that users in each role see just the fields on each NetSuite screen that apply to their work
- Setting up preferred searches for the same purpose
- Applying preferences, such as how PDFs will be handled or whether Inventory Level Warnings will be displayed, via the user's Preferences screen
- Setting up custom dashboards by role (so that every time users log in, they see just the shortcuts and portlets on their home page that help them do their jobs)
These are all important tasks to cover, but they should be straightforward enough that you can quickly mention them and then move on.
What do you want the role's dashboard to have on it?
Each role can have its special dashboard with contents pre-defined to help them focus their efforts in NetSuite. It's not necessary to make a custom dashboard for every single role, but you should look for opportunities to make any group's NetSuite activities easier by creating one, or by showing one of the NetSuite administrators how to do so. Giving people a limited number of shortcuts for only the NetSuite features they will use each day can be a helpful gesture for new users struggling to learn the system.
Which forms and searches should be the roles' preferred versions?
NetSuite allows us to choose special versions of forms and searches for each role. For instance, you might have two sales order searches – one for managers who need to approve them, and another for everyone else. We don't usually worry about this early on in the project, but this is again one of those NetSuite features we want to make sure the client is aware of. Then when the need arises later, they can come in and add forms and searches to a role to tweak it for the users' benefit.
As a member of the implementation team, you should always take advantage of these features to make each user's job as streamlined in the application as possible. Customize their dashboards to suit their needs and provide them with settings and shortcuts which allow them to focus on their unique job duties.
Important Tip
For some clients, as you start to give users access to their NetSuite system, they will ask you for help setting up single sign-on (SSO) as well. This usually involves connecting their NetSuite instance to an external identity provider service (IDP). There are a few bigger, more common companies out there providing this service, but any service that can fully support the NetSuite authentication option known as SAML 2.0 could be used for this. You should be OK just pointing the client to the relevant Help pages and NetSuite Support if they need that kind of help, but keep in mind that SSO is a special setting on the Role as well. Each role is either enabled for SSO or is not. Make sure you're familiar with the highlights of this topic (by reading the Help pages) since it typically comes up very early on in new projects.
Once the roles are set up and you have users signing in with them, there are times when we need to troubleshoot the permissions they're assigned. It's fairly common to have someone report an issue such as the following error from NetSuite: You need a higher permission for 'XYZ' to do this. This error always indicates a permission problem and can usually be sorted out by determining the role the user was logged in with and then reviewing the permissions assigned to that role. The errors are usually spot on and tell us what extra level of access the role needs before the user will be allowed to take whatever action they were attempting.
In the early stages of the project, it's usually true that we don't know enough about every single user to be able to define which role they should receive, but we can at least start the conversation with the client and help them understand all the ramifications of assigning people to roles. Next up, I'll provide one example of a case where this kind of adjustment is needed.
Managing users with multiple roles
As an example, in some cases, we might start with the idea that the people in the A/P department will be given either the A/P Clerk role or the Accountant role but later on, we might find a user who splits their time between both of these activities. We need to maintain accounting rules, such as the separation of duties, but assuming we're safe to give this person all the access they need, we can define one new role for them (including all of the permissions they need) or we can assign them two of the more common roles. In the first case, they can just log in to their account each day and do everything they need. However, then you would have to maintain this additional role over time, just for that person.
With the two roles approach, the user would have to get used to splitting up their time and logging into the account with whichever role they needed to use throughout the day. This can become tedious, but it might still be better, since switching the roles then forces the user to think about what they're doing and when they need to do it. And in my experience, when we decide to use this option, most users will adapt and get used to the switching fairly quickly.
As you've seen, understanding the user groups which make up your client's business is important because it helps us model those people's access to the system, which allows them to get into the product and start doing their jobs. Security and limiting permissions to those who need to know is also important in nearly every business, so we like to be sure the SMEs and managers we train first all know how to set up and change roles in NetSuite as preparation for all the configuration and data creation to come.
Summary
In this chapter, we've covered how to go about beginning the conversation with a client about configuring roles in a NetSuite account, and some of the things that can be tricky about implementing them. Taking the time to find out about any groups of employees the client has at this stage (even if they won't be NetSuite users) will prove valuable for you in the long run, since they can still affect how you configure the account in subtle ways. Also, don't forget what we said about handling users with multiple roles or who need a new custom role to be created just for them. We usually start this process with each client fairly early on in their implementation and then come back to it and tweak the plan as needed right up until going live. Leading your client through this process gives them confidence in your abilities too.
Now that we have this overview in mind and a few people are assigned to a few roles, we can dig into more meaty configuration tasks. So, in the next chapter, we will start to configure an account for finances and accounting.
Self-assessment
Here are a few things related to roles and permissions for you to think about when you're implementing a client:
- If you're working with a client who is very new and doesn't have departments or groups yet, but tells you that they want to start setting things up in NetSuite according to best practices, how can you guide them to the right solution, without creating too much extra hierarchy and so extra work for them now?
- While implementing a client, John, a senior product engineer, tells you that he needs to have the Administrator role to be sure he can get his work done and adjust anything he doesn't like about how NetSuite is set up. How should you respond, and who else from the client's implementation team should be involved in deciding how best to help John work in NetSuite?
- If we say that we won't get every role set up perfectly at the start of a project, when exactly do you think they should be set up? It could be that you could do this just before the UAT starts, or you could put it off until just before going live. There are certainly advantages to waiting, but what might some of the disadvantages be?