How can I limit transaction subsidiary access in NetSuite?

Welcome to OneWorld! You’re starting to get set up in your account and are creating the various roles required in your organization. Everything looks great but then you notice that a specific role you have created (say: role ABC) seems to be able to create transactions for not only the Parent subsidiary but also the Children. What gives? The goal of role ABC was to only give the user access to the Parent subsidiary. So, how is it possible that this role is able to create transactions with other subsidiaries?

Role-based access

Well, in the case outlined above, it is most likely the case that the role has been granted “All” access in the “Accessible Subsidiary” radio button selection as shown below:

As you can see above, there are 4 options to select from when creating a role in NetSuite.

1. All: Grants the role access to all subsidiaries, including inactive subsidiaries.
2. Active: Grants the role access to the active subsidiaries only.
3. User Subsidiary: Restricts the role’s access to the user’s subsidiary only. When users log in with this role, they can only access their own subsidiary. A user’s subsidiary is set on the employee record.
4. Selected: You select the subsidiaries to which you want to restrict the role’s access. When you choose Selected, you need to select the subsidiaries from an autogenerated list of all of the active and inactive subsidiaries. You must select at least one subsidiary.

Which option should I use?

When granting “All” as a permission, proceed with caution. This option is usually reserved for Administrator type roles that need oversight on all consolidated data and requires quite a bit of freedom in NetSuite.

When granting “Active” as a permission, it is essentially the same permission as the “All” except that it does not include inactive subsidiaries. This role may be useful if there is an oversight type role that would not need to see historical transactions (for example a subsidiary that has been inactivated but still contains data).

When granting “User Subsidiary” as a permission, it is pulling the Subsidiary from the Employee record. This is the most common way of setting up a role as you can then manage the Subsidiary the Employee belongs to on the Employee record itself. This lends itself to potentially easier maintenance depending on the use case.

When granting “Selected” as a permission, it is a role that has access to a specific subset of Subsidiaries. This method could also lend itself to potentially easier maintenance as you could change the access of a specific role in one place but affect multiple users using that role.

Cross-Subsidiary viewing

Special mention to the permission “Allow Cross-Subsidiary Record Viewing”, which allows users logged in with this role to see, but not edit, records for subsidiaries to which the role does not have access.