NetSuite subsidiary restrictions on roles determine which company entities a user can work with in a OneWorld account. When the restriction is too narrow, users may be unable to view, create, edit, search, or approve records associated with another subsidiary. The restriction can also interact with the employee record, permissions, transaction context, departments, locations, classes, saved searches, and integrations, so changing a single permission does not always resolve the problem.
The key point is that a role’s accessible subsidiaries are only one layer of NetSuite access. A user must have the right role permissions, belong to the correct employee context, and work with records that fall within the role’s permitted organizational scope. To troubleshoot hidden subsidiary records, compare the role’s accessible subsidiaries with the employee’s assigned subsidiary, the record’s subsidiary, and any additional restrictions on the role or search.
What NetSuite subsidiary restrictions on roles actually control
In NetSuite OneWorld, subsidiaries represent legal entities or operating companies within a shared account. A role’s subsidiary restriction controls the entities that the role is allowed to access when the user performs work in NetSuite.
The setting is generally managed through the role record under Users/Roles > Manage Roles. When editing a custom role, an administrator can select subsidiaries in the role’s Accessible Subsidiaries field. The available choices depend on the account’s OneWorld configuration and the role’s purpose.
This setting affects more than the subsidiary field displayed on a transaction. It can influence:
Which records appear in lists and searches
Which transactions the user can open
Which subsidiary values are available during data entry
Whether the user can create or edit records for a particular entity
Whether reports and dashboards return records from selected subsidiaries
Whether an integration role can process records across multiple entities
Whether approval, fulfillment, billing, or accounting actions are available
A role restriction is not the same as a permission. A user might have Transactions > Sales Order > Full, but that permission does not automatically grant access to every sales order in every subsidiary. The role still operates within its subsidiary scope and any other applicable access rules.
This is why increasing a permission level often fails to solve a subsidiary visibility problem. The permission answers what the user can do with a record type. The subsidiary restriction answers where the user can do it.
Why are subsidiary records hidden from a NetSuite user?
Subsidiary records are hidden when the user’s effective access does not include the record’s subsidiary or when another access condition filters the record. The most common cause is a mismatch between the role’s Accessible Subsidiaries setting and the subsidiary associated with the record.
For example, a user might have permission to view vendor records, but the vendor may be associated with a subsidiary outside the role’s permitted scope. NetSuite can then omit the vendor from a list or saved search rather than display the record with an obvious access-denied message.
Other causes include:
The employee’s primary subsidiary is incorrect. The employee record provides important context for the user. A role may permit several subsidiaries, but the employee setup can still affect available values, defaults, and how the user interacts with transactions.
The role includes additional restrictions. Department, location, class, employee, and other restrictions can narrow the result further. A user might have access to the correct subsidiary but still fail to see a record because it belongs to a restricted department or location.
The record has a different subsidiary than expected. This occurs frequently with vendors, customers, employees, projects, and transactions created through imports or integrations. The visible name may look correct while the subsidiary field places the record outside the user’s scope.
A saved search applies its own filters. Search criteria can exclude records even when the role has permission to view them. The search owner, audience, subsidiary criteria, and available filters all deserve review.
The user is operating in a different role. A user may have multiple roles, but access does not always combine into one unrestricted permission set. Test the exact role selected from the NetSuite role menu.
The account uses subsidiary hierarchy behavior. Parent and child subsidiaries can produce different access results depending on the role configuration and the type of record or report being viewed. Do not assume that access to a parent automatically produces the same result as direct access to every child entity.
For broader role configuration and permission planning, see our guide to NetSuite security roles and permissions for audit access. That article addresses the wider access review process, while this guide focuses specifically on hidden or inaccessible records caused by subsidiary scope.
How do role restrictions differ from employee restrictions?
Role restrictions and employee restrictions operate at different points in the access model. The role defines the capabilities and organizational scope available to a position. The employee record identifies the person using that role and supplies employee-specific information, including subsidiary relationships and other assignments.
A reliable review separates these two records instead of treating them as one configuration.
| Access layer | What to inspect | Typical effect |
|---|---|---|
| Role permissions | Lists, transactions, reports, setup, and custom record permissions | Determines what record types and actions are available |
| Accessible Subsidiaries | Subsidiaries selected on the role | Determines which entities fall within the role’s scope |
| Employee record | Primary subsidiary and assigned details | Supplies user context and transaction defaults |
| Record subsidiary | Subsidiary on the customer, vendor, employee, project, or transaction | Determines whether the record falls inside the permitted scope |
| Additional role restrictions | Department, location, class, employee, and related filters | Narrows access beyond the subsidiary level |
| Search and report criteria | Filters, audience, permissions, and subsidiary criteria | Controls what results the user actually sees |
The important diagnostic principle is that the effective result is cumulative. Access is not simply “the role allows this subsidiary.” The user also needs a compatible employee context, an appropriate permission, and a record that passes the remaining restrictions.
This matters during onboarding and organizational changes. If an employee transfers from one subsidiary to another, updating the employee record without reviewing the role can create confusing results. The employee may see some menus and records but not the transactions expected for the new entity. Conversely, expanding the role without updating the employee record can create incorrect defaults and reporting context.
How to troubleshoot hidden records step by step
Troubleshoot the exact record and exact user rather than reviewing the account broadly. A controlled comparison produces a more reliable result and avoids unnecessarily expanding access.
1. Identify the record’s subsidiary
Open the affected record with an administrator or a role that can confirm the subsidiary value. Record the subsidiary shown on the transaction, customer, vendor, employee, project, or custom record.
Do not rely on the record name, legal name, or business unit label. In a OneWorld account, the subsidiary field is the controlling data point for many access decisions. For transactions, also check related records because the transaction subsidiary, customer subsidiary relationship, and originating record may not all tell the same story.
For imported or integrated records, inspect the integration mapping and source payload. A missing or incorrectly mapped subsidiary value can route a record into an unexpected entity or cause a downstream role to exclude it.
2. Confirm the active role
Ask the user to confirm the role currently selected in NetSuite. Administrators frequently test with an administrator role and conclude that the configuration works, while the affected user operates with a custom finance, sales, operations, or integration role.
Use the role’s internal configuration as the source of truth. The role name alone is not sufficient because two roles with similar names can have different permission levels and subsidiary settings.
3. Review Accessible Subsidiaries
Open the role and inspect Accessible Subsidiaries. Confirm that the record’s subsidiary is selected and that the selection reflects the intended scope.
Review whether the role is designed for one entity, a group of entities, or a shared-services function. Selecting every subsidiary can make the error disappear, but it weakens least-privilege access and complicates audit review. The correct setting is the smallest scope that supports the user’s responsibilities.
For help with broader OneWorld design, subsidiary hierarchy, and access controls, our NetSuite services cover multi-entity configuration and governance alongside financial and operational processes.
4. Compare employee context
Open the employee record and compare its primary subsidiary and related assignments with the role design. If the employee recently changed legal entities, confirm that the employee record was updated intentionally and that historical transactions remain appropriately associated with the original subsidiary.
Also check whether the user is an employee, vendor, partner, or another supported NetSuite user type. User type and record relationships can affect what access patterns are available.
5. Check permissions and restriction subtabs
After confirming subsidiary scope, inspect the role’s permission subtabs. Review the permission category, record type, and access level. A user who needs to edit a record must not be limited to View access, even if the subsidiary is correct.
Then inspect additional restrictions for department, location, class, employee, and related organizational dimensions. These filters can make a subsidiary correction appear ineffective because another restriction still excludes the record.
This is particularly important for financial roles. A user might need access to a subsidiary’s transactions but not to every department or location within that subsidiary. Preserve those narrower boundaries unless the job responsibility genuinely requires broader access.
6. Test the record, search, and workflow separately
Test direct record access first. Then test the list, saved search, dashboard, report, workflow, and integration that originally exposed the problem. A direct record test and a search test are not interchangeable.
A saved search might include a subsidiary criterion, a filter based on the current user, or an audience restriction. A workflow might run under a role with a different permission context. An integration might use an authentication role that has narrower subsidiary access than the employee role.
Record the result of each test. This creates a useful audit trail and prevents repeated permission changes without knowing which change resolved the issue.
Why saved searches and reports show incomplete subsidiary data
Saved searches and reports frequently create the impression that a role cannot access a record when the underlying record permission is correct. The search may have criteria that limit subsidiaries, use fields unavailable to the role, or return results differently under the current user’s restrictions.
Start by comparing the result under an administrator role and the affected custom role. If the record appears for the administrator but not the user, review the role and search configuration together. If it does not appear for either role, inspect the search criteria and record status before changing permissions.
Pay attention to these details:
Criteria that name a specific subsidiary
Filters that use the user’s employee, department, or location
Search audiences and public versus private ownership
Summary searches that group records by subsidiary
Inactive records excluded by default or explicit criteria
Results that rely on joins to restricted record types
Reports using accounting book, period, or consolidation settings
A report can also present consolidated data differently from a transaction search. Consolidated reporting may include multiple subsidiaries, while operational record access remains restricted. Never use a consolidated report as proof that the user can open every underlying transaction.
What subsidiary restrictions mean for integrations
Integration roles need special attention because an automated process can cross subsidiary boundaries even when a human user does not. NetSuite integrations commonly create or update customers, vendors, sales orders, invoices, item records, payments, and custom records. The authentication role must have access to every legitimate subsidiary involved in the process.
At the same time, broad access is not a safe default. An integration role should not receive access to every subsidiary simply because one workflow occasionally touches more than one entity. Define the integration’s data flow first, then configure the narrowest role scope that supports it.
Review:
The authentication method and role used by the integration
Subsidiaries present in inbound payloads
Default subsidiary values applied by scripts or mappings
Cross-subsidiary transactions and intercompany processes
Error logs that identify rejected or inaccessible records
Whether the integration creates records under a user or system context
Custom records that lack the same subsidiary behavior as standard records
When an integration returns “record not found,” “permission denied,” or a similar error, do not immediately assume the record was deleted. The authentication role may be unable to see the record because of subsidiary restrictions. Our NetSuite Avalara permission error guidance explains why transaction context, primary subsidiary, accessible subsidiaries, and related restrictions should be reviewed together.
How to change subsidiary access safely
Change subsidiary access through a controlled role-management process. First document the business requirement, affected record types, required actions, and entities involved. Then update the custom role rather than modifying an administrator role or creating a broad exception for one user.
After saving the role, test with a non-administrator account or the affected user in a controlled window. Confirm both positive and negative cases: the user should access the newly required subsidiary, but should still be blocked from entities outside the approved scope.
Use system notes and role-change records to document who changed the restriction, why the change was needed, and how it was tested. NetSuite access reviews are stronger when the configuration change can be connected to a business responsibility rather than an unexplained support request.
Avoid solving the problem by:
Giving the user an administrator role
Selecting every subsidiary without documenting the need
Duplicating several nearly identical roles without ownership
Removing department or location restrictions unnecessarily
Changing the employee’s primary subsidiary only to make a record visible
Granting broad permissions when the issue is limited to subsidiary scope
If a role serves users across multiple legal entities, create a clear access model. Separate shared-services roles from entity-specific roles, define which records require cross-subsidiary visibility, and review the design when new subsidiaries are added.
When should a NetSuite consultant review subsidiary restrictions?
A specialist review is appropriate when access problems continue after the role, employee, record, and search settings have been compared. It is also valuable when subsidiary access affects integrations, intercompany accounting, consolidated reporting, approvals, or sensitive employee and financial data.
Complexity increases when the account includes multiple currencies, tax environments, accounting books, custom records, workflows, scripts, and external integrations. In those environments, a role change can solve one user’s problem while creating unintended access elsewhere.
A structured review should produce more than a revised role. It should clarify the intended access matrix, identify conflicting restrictions, document integration roles, and establish a repeatable review process for new employees and subsidiaries. If you need help evaluating a role design or correcting cross-subsidiary access, contact Versich to discuss your NetSuite requirements.
Conclusion
NetSuite subsidiary restrictions on roles determine where users can work, but they do not operate in isolation. Hidden records result from the combined effect of role permissions, accessible subsidiaries, employee context, record subsidiary, additional restrictions, search criteria, workflows, and integration roles.
The safest troubleshooting method is to compare those layers in order, starting with the record’s subsidiary and the user’s active role. Expand access only when the business requirement is clear, test both allowed and excluded records, and document the change for future audits. A precise subsidiary access model protects sensitive data while allowing finance, operations, shared services, and integrations to work across the entities they legitimately support.
