NetSuite Custom Record Permissions for Safer Role Access
A NetSuite custom record permission issue usually comes from a mismatch between the role’s record-level access, the custom record’s access settings, the employee’s assigned role, or the form and workflow controlling the record. To resolve it safely, we first confirm that the role has the correct Custom Record permission, then verify the permission level, audience, subsidiary restrictions, custom record access configuration, and any script or workflow conditions. Testing with Administrator access helps isolate whether the problem is security-related or caused by record logic.
NetSuite custom records are flexible, but that flexibility creates several layers of access control. A user might be able to see a custom record but not edit it, create new records but not view existing ones, or access the record through a search while being blocked from opening it directly. The right fix depends on the exact behavior.
What does the Custom Record permission control in NetSuite?
The Custom Record permission controls whether a role can work with a specific custom record type and what actions that role can perform. The permission is assigned to the role under Permissions > Lists, where the administrator selects the relevant custom record and sets an access level such as View, Create, Edit, or Full.
This permission does not operate in isolation. NetSuite evaluates it alongside:
The custom record type’s Access settings
The role’s subsidiary, department, location, and class restrictions
Employee and vendor access restrictions
Custom forms and field-level display settings
Workflows, SuiteScript, and User Event scripts
The record’s owner and access configuration
Whether the user is working through the UI, a saved search, Suitelet, RESTlet, or integration
For example, a role with Edit permission might still be unable to update a record if the custom record type only grants access to a limited audience. Similarly, a role with Full access may still encounter a validation error caused by a workflow or script rather than by permissions.
The first diagnostic question is therefore not simply, “Does the role have access?” It is, “Which layer is denying or changing the requested action?”
Why can a NetSuite user view a custom record but not edit it?
A user who can view a custom record but cannot edit it typically has a View-level permission, a restricted custom record audience, or an edit-blocking workflow or script. NetSuite separates access levels, so seeing a record does not imply that the role can change it.
Review the role’s permission line first:
Go to Setup > Users/Roles > Manage Roles.
Edit the role assigned to the affected user.
Open Permissions > Lists.
Locate the specific custom record type.
Confirm that the level is Edit or Full, depending on the required business action.
Save the role and test again using the affected user or a controlled test account.
The distinction between Create, Edit, and Full matters. Create generally allows a user to add records without granting broad authority over existing records. Edit allows changes to records the role can access. Full provides the broadest record-level control and should be reserved for users who genuinely need it.
A role can also display the custom record in a search while blocking the record page. Saved search visibility should not be treated as proof that direct record permission is correctly configured. Search results, list views, dashboards, and record pages can expose different symptoms depending on the underlying access path.
How do you fix a custom record permission issue in NetSuite?
The safest approach is to isolate the failing action, compare role access with custom record access, and test one change at a time. Avoid immediately assigning Administrator access or Full permission to a production role because that can conceal the real cause and create unnecessary exposure.
1. Reproduce the exact access failure
Record what the user is trying to do and what happens. “The custom record does not work” is not specific enough for effective troubleshooting. Identify whether the user cannot:
Find the record in navigation
Open an existing record
Create a new record
Edit a saved record
Delete a record
See a field or sublist
Submit a record
Use the record in a saved search
Access the record through an integration or script
Capture the exact error message, URL behavior, record ID, role name, and approximate time of the failure. These details help distinguish permission errors from workflow validation, mandatory-field errors, and script failures.
If the user receives “You do not have permission to access this record,” focus on role and record access. If the page opens but Save fails, inspect workflows, scripts, mandatory fields, and field sourcing as well.
2. Confirm the user’s active role
NetSuite users can have several assigned roles, but only the currently selected role controls the active session. Confirm the role shown in the user’s role menu before changing configuration.
A common testing mistake is editing one role while the user is actually working in another. This occurs frequently when users switch between standard roles and custom roles for finance, operations, or administration. It also affects SSO testing, because the identity provider may launch a particular NetSuite role based on role mapping.
For a related troubleshooting approach, our guide on isolating NetSuite role issues with a non-SSO test role explains why a controlled test role can help separate authentication problems from authorization problems.
3. Review the role permission and access level
After confirming the active role, inspect the specific custom record permission under Permissions > Lists. Check that the correct record type appears and that the level matches the requested action.
Also review restrictions in the role’s Restrictions section. Subsidiary, department, class, and location restrictions can affect whether records appear or whether users can interact with them. A user might have Edit permission but be restricted to a subsidiary that does not own the target record.
Do not assume that adding the record permission automatically grants access to every related field. Custom fields can have their own audience, role, and display settings. A user who can open the record but cannot see a required field may be experiencing field-level configuration rather than a record permission failure.
4. Check the custom record type’s Access configuration
Open the custom record type and review its access settings. Depending on the record configuration and account setup, the custom record may define access by role, employee, department, subsidiary, group, or other audience criteria.
Pay close attention to whether access is granted to:
Specific roles
All roles
Selected employees
The record owner
The employee hierarchy
Users associated with a subsidiary
Users meeting a defined audience condition
The custom record type’s access settings can narrow the practical result of a role permission. A role may have Edit permission in the role record, but the custom record type may only permit that role to view records or may exclude the relevant employee entirely.
This is also where ownership matters. If access is based on the record owner, changing ownership can change who can view or edit the record without changing the role permission itself.
5. Test the record form and fields
If the user can access the custom record but cannot complete the transaction, review the custom form. A form can hide fields, make fields mandatory, alter field sourcing, or present a different set of sublists.
A hidden field may still be required by a workflow or script. In that situation, the user sees what appears to be a permission or save problem, but the real issue is that the form does not expose the value needed to submit the record.
Compare the affected user’s form with the Administrator form and a controlled custom-role form. Look for:
Hidden or disabled fields
Mandatory custom fields
Different custom forms assigned by role
Restricted sublists
Field-level role permissions
Fields sourced from records the user cannot access
For search-related behavior, a custom field’s Global Search setting controls whether its values are indexed for global search. It does not grant permission to view the record or field. Our article on making NetSuite custom field values searchable covers that separate configuration.
6. Investigate workflows, SuiteScript, and integrations
When permissions appear correct, inspect automation. A workflow may prevent edits based on status, owner, subsidiary, or approval state. A User Event script may reject a record during `beforeSubmit`, while a Client Script may stop the user before submission. A Suitelet or RESTlet can also impose its own role and execution-context behavior.
The execution context is especially important. A script may run differently in the UI, CSV import, web services, scheduled, or Map/Reduce context. A permission issue that occurs only during an integration should not be “fixed” by broadening a human user’s role.
Review script deployments and workflow history for the affected record and time. Look for conditions that reference:
`runtime.getCurrentUser()`
The user’s role
Subsidiary or employee values
Approval status
Record ownership
Custom approval fields
Execution context
Record type or custom form
When possible, reproduce the issue in a sandbox or with a dedicated test role. Make one change, retest the same action, and document the result.
What is the difference between role permission and custom record access?
A role permission establishes what a role is allowed to do with a record type, while custom record access settings determine which users or roles can access particular records. Both layers must permit the action.
| Security layer | Main question it answers | Typical failure |
|---|---|---|
| Role permission | Can this role perform View, Create, Edit, or Full actions on the record type? | The permission is missing or set too low |
| Custom record access | Is this user or role included in the record type’s audience? | The role is excluded from the access list |
| Record restrictions | Does the record fall within the role’s subsidiary, department, location, or class scope? | The record is outside the role’s restriction |
| Field and form settings | Can the user see and complete the fields required for the action? | A required field is hidden or unavailable |
| Workflow and SuiteScript | Is automation allowing the requested change? | A workflow or script blocks Save |
| Integration context | Is the request running under a role and execution context with sufficient access? | The integration role lacks a required permission |
This distinction prevents a common configuration error. If a user needs access to one record, do not automatically grant Full permission to the entire custom record type. First determine whether the requirement is broad role access or targeted record access.
How should you test NetSuite permissions without creating a security risk?
Use a dedicated test role that mirrors the affected role and change only the permission under investigation. This produces a reliable comparison without changing the user’s production access or relying on Administrator behavior.
Administrator testing is useful as a diagnostic baseline, but it is not a final solution. If Administrator can edit the record and the affected role cannot, the problem is probably authorization, restriction, form access, or automation tied to the current user. If Administrator also fails, the issue is more likely related to record configuration, workflow logic, mandatory fields, or a script.
A useful test matrix includes the following scenarios:
| Test | What it reveals |
|---|---|
| Administrator opens the record | Whether the record itself is available |
| A copied role with the expected permission opens it | Whether the original role differs from the intended configuration |
| The affected user tests in the corrected role | Whether the change solves the real user experience |
| The same role tests another record | Whether the issue is record-specific |
| UI action compared with CSV or integration action | Whether execution context changes the result |
Keep the test role inactive after the investigation if it is no longer needed. Limit its employee assignments, avoid copying unnecessary permissions, and document every temporary change.
How do you prevent custom record permission problems?
Preventive controls begin with a permission design that reflects job responsibilities rather than convenience. Custom record permissions should be reviewed alongside the business process, record ownership model, approval rules, and integration architecture.
Use least privilege as the baseline. Grant View when users only need reference access, Create when they need to originate records, Edit when they must maintain records, and Full only when administrative control is justified.
Document the following for every important custom record:
The business owner
The roles that can view, create, edit, and delete
The record ownership rule
Subsidiary and organizational restrictions
Required fields and custom forms
Workflows and scripts that modify access or status
Integration roles and execution contexts
The process for reviewing permission changes
System Notes can help identify when role, record, or field configuration changed. Keep in mind that System Notes show configuration and record activity, but they do not replace a structured permission test. A current configuration snapshot and a repeatable test case provide stronger operational control.
Delete access deserves special attention. A role that can edit a record does not necessarily need the ability to delete it. Also, a custom record may be referenced by List/Record fields elsewhere in NetSuite, which can create dependency errors when deletion is attempted. For the separate issue of why a referenced custom record cannot be deleted, see our guide to the NetSuite custom field setting that affects record deletion.
When should you ask for NetSuite permission support?
Ask for specialist support when the issue spans roles, subsidiaries, workflows, SuiteScript, integrations, or sensitive financial data. Permission changes that seem small can expose records across organizational boundaries or disrupt automated processing.
Support is particularly valuable when:
The same role behaves differently for different employees
Access depends on subsidiaries or employee hierarchies
The issue occurs only in CSV imports, web services, or scheduled scripts
A workflow or script appears to override role permissions
The error is inconsistent or difficult to reproduce
The required fix would involve Full permission
The change affects confidential financial, employee, vendor, or customer data
We help organizations review NetSuite security configurations, isolate permission failures, and implement controlled fixes. If you need assistance with a custom record access problem, contact Versich for NetSuite support.
Conclusion
NetSuite custom record permission issues are rarely solved safely by adding Administrator access or assigning Full permission without investigation. The reliable method is to identify the exact failing action, confirm the active role, review the role’s Custom Record permission, inspect custom record Access settings, check organizational restrictions, and then investigate forms, workflows, SuiteScript, and integrations.
A controlled test role and a documented permission matrix make the resolution easier to verify and reduce the risk of overexposure. When several security layers interact, a structured review protects both usability and data governance while delivering the access users actually need.
