Design NetSuite role restrictions by specifying both the action a person may perform and the records on which they may perform it. Then test the intersection of subsidiary, department and other relevant restrictions with the person's active role. A correct transaction permission can still produce missing records, while an overly broad viewing option can expose more information than intended.
This is a boundary-testing exercise for OneWorld and departmental access. It goes beyond a general role inventory by comparing permitted, prohibited and deliberately shared records. The outcome should be a small access matrix with clear exceptions, rather than a sequence of increasingly broad permissions added until one troublesome record appears.
Replace requests such as “give finance access” with specific statements. A local billing specialist might create invoices for one subsidiary and department, view approved shared customer details and have no role in purchasing. A shared-services reviewer might view several subsidiaries without editing their transactions.
Identify whether the restriction is meant to control viewing, selection of field values, creation, editing or another operation. These are different outcomes. A user who can select a subsidiary in a field has not necessarily demonstrated permission to open or change every transaction associated with it.
Document the record types involved. Standard transactions, employees, items and custom records do not share an identical access model. A policy that says “everything in department A” needs to be translated into the supported restrictions and tested record by record.
Name the owner who can approve exceptions. Shared suppliers, intercompany activity and central collections can require legitimate cross-entity visibility. Establish those needs before troubleshooting so a missing record does not become an informal approval to remove boundaries.
In OneWorld, role subsidiary scope can use All, Active, User Subsidiary or Selected. All includes inactive subsidiaries; Active excludes them. User Subsidiary derives its scope from the employee's subsidiary. Selected limits the role to the chosen subsidiary set.
Choose according to the responsibility. A role intended for a named regional group usually needs a maintained explicit scope. A role intended to follow each employee's home entity needs tests involving employees in different subsidiaries, including any planned transfer between entities.
Review Allow Cross-Subsidiary Record Viewing separately. It is a viewing exception, not a general grant of editing rights. Employee payroll and commissions are excluded from that option, and an applicable Book Record Restriction takes precedence. Treat these constraints as reasons for targeted testing rather than assuming the checkbox resolves every cross-entity request.
A personal subsidiary-view preference is also different from the role's authorized access boundary. It can change what a user is currently looking at without granting a missing permission. Record both settings during investigation so a view filter is not mistaken for a security failure.
Department restrictions require particular attention to hierarchy and unassigned values. Define whether child departments belong in scope and whether a record lacking a department should be visible. An unassigned record is often exactly where a control failure hides.
The options for own-and-subordinate scope differ according to whether unassigned values are included. Do not read “none, default to own” as a restriction: it supplies a default without using that field to restrict record access. A default can make a form look correct while leaving a much wider set of choices available.
Check record-specific exceptions. For example, accounts in the Chart of Accounts with no department assignment are not constrained by the two own-and-subordinate department options in the same way. Department-based access can also be extended to items through Apply to Items. These details make a universal “department blocks all data” claim unsafe.
Review the department Allow Viewing option on its own terms. It excludes employee payroll and commission data, and it does not allow viewing non-subordinate departments when the restriction is own and subordinates only. Do not confuse this option with the separate cross-subsidiary viewing setting.
Use representative records with known classifications. Include the employee's department, one child, a sibling, a blank value and a record in a different subsidiary. Test the actual combinations that exist in the business, rather than relying on a diagram of the organization alone.
For each role, record the employee context, subsidiary, department, record type and requested operation. Give every row an expected result before executing it. Use distinguishable outcomes such as allowed, denied, visible without edit, or intentionally outside the test scope.
A useful minimum set includes:
Add an item or employee case only when the role's work requires it. Avoid populating the matrix with irrelevant combinations merely to increase its size. The purpose is to demonstrate the approved boundary and expose the places where supported behavior differs from the business assumption.
Run the matrix through direct record access and the important reporting or custom-interface route. Keep result visibility and drilldown distinct. A saved search with special execution settings deserves its own review; its displayed totals cannot prove the underlying role is appropriately restricted.
A fictional company has three subsidiaries and two departments in each. A collections analyst should edit receivables-related records for subsidiary A's Services department and view an approved set of records in subsidiary B. Subsidiary C remains outside the analyst's responsibility.
The administrator prepares twelve test combinations: six organizational populations multiplied by two operations, view and edit. The business owner expects one population to allow both actions, one to allow viewing only and four to deny both. That produces three allowed operation results and nine denials.
An initial test reveals that a broad cross-subsidiary viewing setting exposes records in subsidiary C as well. The team does not accept the change because the requested subsidiary B record is now visible. It revisits the supported design and chooses a narrower approved solution, then repeats the matrix.
The example illustrates acceptance logic rather than a universal configuration recipe. Additional record permissions, employee restrictions, accounting-book rules and custom-record behavior must be tested in the actual account.
When an allowed case fails, first confirm the precise role and account. Check that the record exists in the expected environment and that its classifications match the test specification. A recently changed subsidiary or blank department can explain the outcome without any defect in the permission model.
Next compare the operation permission with the organizational restriction. Keep these investigations separate. Raising an access level will not necessarily solve an excluded subsidiary, and removing a subsidiary restriction may unnecessarily expose many records while leaving a missing record-type permission unresolved.
For custom records, inspect their own permission model and configured restriction fields. For employee information, review the account's employee permission features rather than treating it as ordinary transaction data. Integrations also need their own active identity and role tests.
Change one supported setting at a time in a controlled environment. Record which matrix rows change and which remain unchanged. This makes the effect explainable and prevents a successful positive case from concealing a newly failed negative case.
An exception record should name the business need, affected users, data population, permitted actions, owner and expiry or review condition. A temporary cover arrangement should not silently become permanent access after the absent employee returns.
Review role scope when subsidiaries, departments or reporting responsibilities change. Adding a new subsidiary can alter the reach of a broad option, while a renamed department can hide the fact that its underlying responsibility has changed. Repeat the relevant boundary cases after the approved update.
Use CuriousRubik's NetSuite support services when the access design crosses several record models or conflicting restrictions. The objective is evidence that necessary work succeeds and unrelated access remains appropriately constrained.
No. Operation permissions and organizational restrictions are separate parts of access. Check both against the precise record and active role before changing either.
The none, default-to-own department option supplies a default without imposing that department access restriction. Validate the chosen option and test records outside the employee's department.
Yes. Blank classifications can behave differently from assigned records and may represent real exceptions. The business owner should decide the intended treatment before the access test.
It is a viewing option, with documented exclusions and accounting-book interactions. Test the exact records and operations instead of treating it as unrestricted cross-entity access.
The business populations can be reused, but execute them through the integration's actual identity, role and channel. An employee's successful interactive session does not establish API access.