1. Employee Management
  2. Employees
  3. Advanced Employee Permissions
  4. Before Enabling the Advanced Employee Permissions Feature
  5. Advanced Employee Permissions and SuiteScript

Advanced Employee Permissions and SuiteScript

In NetSuite, account administrators have access to all the information on all record types, including the employee record. This can create issues in the following situations:

A user could write or deploy a script that gains access to employee information that they would normally not have access to. This could potentially be used to compromise employee information.

When Advanced Employee Permissions is enabled, carefully track which roles have permission to create or alter scripts. In addition, track which scripts execute as administrator, and what they do to make sure employee information is not unintentionally leaked.

Assigning any of the Advanced Employee Permissions to a role gives partial access to the employee record. Some scripts (including third-party scripts) may fail when users attempt to access parts of the employee record that they are not permitted to access. For more information, see Advanced Employee Permissions Overview.

If needed, consider running these scripts as administrator, or revise the scripts to handle cases where some fields and sublists are not accessible.

If you have any scripts that add buttons to the employee record, ensure that they appear only when appropriate. Configure scripts so that the action being added respects the restrictions on the employee record.

Script Access

The following section outlines how script access changes when Advanced Employee Permissions is enabled.

The fields and sublists a user has access to can change depending on which employee record is being viewed or edited. This is different from other records in NetSuite, where permissions granted to a role determine just the instances of the record the role can see.

The search columns available to users are also dependent on the permissions assigned to the role.

In general, scripts should always check to see if the role has access to a field or sublist before trying to do something with it. Simply calling functions and methods that interact with fields and sublists before checking whether the role has access may result in inconsistent behavior.

For example, the Department field is permitted on the employee record. You do not have access, therefore, a null value is returned. If the field is empty, an empty string is returned.

Script Access Examples

When you run the following script, errors generate because the script does not check if the field exists, or whether you have access to it.

              var employeeRecord = nlapiLoadRecord('employee', '115');
employeeRecord.setFieldValue('department', '2');
nlapiSubmitRecord(employeeRecord);

To check if your role has access to a field for a specific employee, load the employee record object and call getAllFields().includes(). If the field exists and you do have access, a true value is returned. In the following example, the user has access to the Department field for the employee with ID:115.

              var accessToDepartment = nlapiLoadRecord('employee', '115').getAllFields().includes('department');

Taking the previous two script examples into consideration, you should use the following example to make sure your scripts do not fail.

              var employeeRecord = nlapiLoadRecord('employee', '115');
var hasAccessToDepartment = employeeRecord.getAllFields().includes('department');
if (hasAccessToDepartment)
{
      employeeRecord.setFieldvalue('department', '2');
}
nlapiSubmitRecord(employeeRecord);

For more information about working with SuiteScript, see Suitelets and UI Object Best Practices and Client Script Best Practices.

Related Topics

General Notices