Executing Scripts Using a Specific Role
The Execute as Role field provides role-based granularity in terms of the permissions and restrictions for executing scripts. For example, if a Sales Person role is selected in the Execute as Role field (see figure below), the script will always execute based on the permissions and restrictions assigned to the Sales Person role, even if the role of the logged in user is different. For example, if the logged in user’s role is Administrator, when the script executes in this user’s account, it executes based on the record-level permissions assigned to the Sales Person role and not that assigned to the administrator role.
The Current Role value in the Execute as Role field means that the script executes using the permissions of the currently logged-in user (the user whose account the script is running in).
SuiteScript developers can also select from custom roles that they have created with permissions that are specific to a script deployment.
The Execute as Role field is available on the Script Deployment pages for these script types only:
-
Suitelet
-
User Event
-
Portlet
-
Mass Update
-
Workflow Action
Be aware that when a script triggers other scripts, the cascading scripts will run as the role of the initial triggering script's role, not the role specified on the cascaded script's role.
For information about SuiteScript roles and permissions, see Setting Roles and Permissions for SuiteScript. For information about role restrictions in client SuiteScript, see Client Script Role Restrictions.
Testing a Script Using Different Roles
NetSuite lets you switch the deployment status to Testing when you are setting the script to execute as a different role. When you do this, the script will be triggered only by you. And, when it executes, it will execute as the role you selected.
Setting Your Script to Run With Administrative Privileges
If you want the script to execute using administrative privileges, regardless of the permissions of the currently logged-in user, select Administrator in the Execute as Role field.
There may be some scripts that are required to run with administrative privilege. For example, if you have a script that creates follow-up tasks after a sales order has been saved, and the script needs to read data from employee records, the script will not complete execution if a user's role does not have permission to access employee records. In this case, it may be appropriate to have Administrator selected in the Execute as Role field.
However, setting a script to execute as Administrator should be done with caution, as this option allows scripts to execute with privileges that the logged in user does not have. This may be appropriate for certain scripts, but there are other cases where the script performs actions that are only appropriate for certain roles.
All bundle installation scripts need to execute as Administrator, so Administrator must be selected in the Execute As Role field for those scripts.
Often, when scripts execute without logins (see Setting Available Without Login) or in the Web store, they tend to be implemented as an Administrator whenever any meaningful interaction with the system is required.