Role and Permission Considerations When Developing in SOAP Web Services
Due to SOAP web services’ being reliant on the NetSuite role-based permissions, SOAP web services developers should consider this during the design phase for smooth deployments.
Developers often use the administrator role during development for full permissions and access to all records and operations. However, the target users may have limited roles, restricting access to required data
Some roles' custom forms may lack access to fields or sublists needed by the SOAP application. This can cause permission errors when the application tries to access those fields.
Define a custom role and custom forms for the SOAP application to solve these problems. The custom role should have the correct access permissions and operations permissions that the SOAP web services application needs. The custom forms should give access to fields and sublists that are relevant to the SOAP application. All SOAP web services supported records have a customForm field for the application to reference specific custom forms.
In 2016.2, a permission has been added to the Role page on the Permissions > Setup subtab. If the Control SuiteScript and Workflow Triggers in Web Services Request permission is selected, users cannot change the setting for scripts and workflow triggers on individual SOAP web services requests. For users who don't have permission to disable scripts, the global setting for the account applies for all of their requests.
When testing SOAP web services applications, you should do so using the role(s) of your intended users(s), in addition to the administrator role, to catch permission-related defects.