# Fix NetSuite INSUFFICIENT_PERMISSION Error > Source: https://netray.co/erp-help/netsuite-insufficient-permission-error > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer INSUFFICIENT_PERMISSION means the role executing the request, whether a logged-in user or the role behind a script deployment, lacks a specific permission needed for the record type, transaction type, or subsidiary being accessed. Fix it by checking the role's permission list under Setup > Users/Roles > Manage Roles against the exact record and level (View, Create, Edit, or Full) the operation requires. ## Kind error ## System netsuite ## Erp Oracle NetSuite ## Module Roles & Permissions ## Query NetSuite INSUFFICIENT_PERMISSION error ## Alternate Queries - You do not have permission to access this page NetSuite - NetSuite INSUFFICIENT_PERMISSION SuiteScript fix - NetSuite RESTlet 403 insufficient permission ## Applies To NetSuite roles and permissions, SuiteScript execution roles, RESTlet/SuiteTalk token-based authentication, all account tiers including OneWorld ## Steps ### How to fix INSUFFICIENT_PERMISSION **Items:** Read the full error text; NetSuite usually names the permission category, such as Transactions > Sales Order, that is missing, not just a generic denial. Identify which role actually executed the failing action: for UI actions it is the logged-in user's current role; for scheduled or Map/Reduce scripts it is the role set on the script deployment's Run As field, not the developer's role. Go to Setup > Users/Roles > Manage Roles, open the relevant role, and check the Permissions subtab for the specific record type or transaction type at the required level. For OneWorld accounts, check subsidiary restrictions on the role separately from the permission level; a role can have Full permission on Sales Order but still be denied if the specific subsidiary is not in the role's subsidiary restriction list. For token-based integrations (TBA or OAuth 2.0), confirm the integration record's token was issued for a role that has the required permissions, and that the role also has Log in using Access Tokens and SOAP or REST Web Services permissions enabled. For custom records, check the custom record type's own Permissions subtab under Customization > Lists, Records & Fields > Record Types, since custom records can restrict access independently of standard role permissions. After changing a role's permissions, have the affected user log out and back in, or re-issue the access token, since permission changes do not always apply to an active session immediately. ## Sections ### Reading the actual error **Body:** NetSuite's INSUFFICIENT_PERMISSION message typically includes the specific area it denied, for example a phrase naming the exact permission required to access the page. This is the fastest way to know exactly which permission to add, rather than guessing across the whole role. When the error surfaces from a SuiteScript execution rather than direct UI navigation, the script's own error handling may wrap or truncate the underlying NetSuite message, so check the raw error object's message and name properties in the Script Execution Log rather than only a custom error string your script logged. ### Scripts run as a specific role, not the developer **Body:** A very common source of confusion: a script works fine when the developer tests it, because their role has Administrator-level access, but fails with INSUFFICIENT_PERMISSION once deployed, because Scheduled Script and Map/Reduce deployments execute under whatever role is set in the deployment record's Run As field, which is often a more restricted integration or automation role. Suitelets and RESTlets, by contrast, execute under the permissions of the calling user's session or the token's associated role, so the fix there is to adjust that specific role rather than the script owner's role. ### OneWorld subsidiary and custom record nuances **Body:** On OneWorld accounts, permissions are layered with subsidiary restrictions. A role can show Full access to Sales Order in the Permissions subtab but still be denied on a specific transaction if that role's subsidiary restrictions do not include the transaction's subsidiary, which produces the same INSUFFICIENT_PERMISSION error and is easy to miss because the permission level itself looks correct. Custom record types have their own independent Permissions subtab that can restrict access below what the role's global permissions would otherwise allow; a role with Administrator-level custom record access can still be blocked on one custom record type if that type's Permissions subtab is deliberately restricted. ## Pitfalls - Testing a script under an Administrator role and assuming it will work identically once deployed under a restricted automation role. - Overlooking subsidiary restrictions on a OneWorld role when the permission level itself looks sufficient. - Forgetting that custom record types have their own Permissions subtab separate from global role permissions. - Not re-issuing an OAuth token or refreshing a session after changing role permissions. - Assuming a 403 or INSUFFICIENT_PERMISSION from a RESTlet is an authentication problem when it is actually an authorization problem on an otherwise valid, authenticated token. ## Ai Angle ERPray, grounded on your account's actual role and permission configuration, can answer which permission an integration role needs to update a specific transaction status directly against your real roles rather than generic documentation, and can flag subsidiary restriction mismatches that are otherwise easy to miss in the Manage Roles UI. For a failing scheduled script, it can also identify the deployment's Run As role and cross-check it against the specific permission the failing API call requires. ## Faq ### Why does my script fail in production but work in sandbox? **Answer:** Roles and their permissions, and the Run As role on a script deployment, are configured separately in each account. A deployment's Run As role in sandbox may have broader permissions than the equivalent role in production, or the deployment record itself may not have been migrated with the same Run As setting. ### Does the Administrator role ever get INSUFFICIENT_PERMISSION? **Answer:** Rarely, but yes, most often on custom record types with an explicitly restrictive Permissions subtab, or where a feature-level permission such as SOAP or REST Web Services has not been enabled even though the role otherwise has full record-level access. ### Is this the same as a 401 Unauthorized on the REST API? **Answer:** No. A 401 usually means authentication failed. INSUFFICIENT_PERMISSION means authentication succeeded but the authenticated role lacks the specific permission for the requested operation, which typically surfaces as a 403 with this error code in the response body. ### Do permission changes apply immediately? **Answer:** Usually yes for new logins and new API tokens, but an already-active UI session or a cached token session may need the user to log out and back in, or the integration to re-authenticate, before the new permission takes effect. ## Search terms INSUFFICIENT_PERMISSION NetSuite, NetSuite you do not have permission error, NetSuite role permission fix, NetSuite Run As role script, NetSuite RESTlet 403 error, NetSuite OneWorld subsidiary permission, NetSuite custom record permission, NetSuite token based authentication permission --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json