Role and Permission Considerations When Developing in SOAP Web Services
Due to SOAP web services’ reliance on the NetSuite role-based permissions, it is important for SOAP web services developers to put that into considerations during the design phase to ensure smooth deployments.
It is common for developers to use the administrator role during development time because it gives them full permissions and access to all the records and operations. However, the target end users are likely to have less powerful roles, which may not have access to the data the SOAP web services application requires.
Another role-related consideration is the preferred custom forms of some roles may not have access to certain fields or sublists that a SOAP application requires. Hence the application's attempts to set those fields will result in permission errors.
The solution to these problems is to define a custom role and custom forms for the SOAP application. 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 do not 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.