🔐 Managing Roles & Permissions for Custom Records and Scripts in NetSuite

Introduction

NetSuite’s flexibility comes with responsibility — controlling who can see, edit, and execute what.
Properly managing roles and permissions ensures your users have the right level of access while protecting sensitive financial data, scripts, and custom records.

In this tutorial, we’ll cover how to:

• Set up and customize roles
• Secure custom records and SuiteScripts
• Manage field-level and workflow access
• Troubleshoot permission errors (like “You do not have permission to access this record”)

💡 Why Role Management Matters

🧱 Understanding NetSuite Role Structure

Roles determine what records, pages, and actions a user can access.

Each role is made up of:

• Permissions (Record, Transaction, Setup, Lists)
• Access Levels (View, Create, Edit, Full)
• Restrictions (Subsidiary, Department, Class)
• Script and Workflow Executions

Default vs Custom Roles

⚙️ Step-by-Step: Creating a Custom Role

Step 1: Navigate to Role Setup

Go to:
Setup → Users/Roles → Manage Roles → New

Step 2: Define Basic Info

Step 3: Add Permissions

a. Record Permissions

Add:

• Custom Record: Full
• Transactions: View/Edit as needed
• Lists → Employees, Customers, Vendors: View

b. Setup Permissions

Add:

• Script Deployment: View or Edit (for developers)
• Custom Record Types: Edit
• Workflow Management: Full (if creating workflows)

c. Lists Permissions

Include access to lists related to the record (Items, Subsidiaries, Departments).

Step 4: Assign Role to Employee

Go to:
Lists → Employees → Employees → Edit Employee → Access Tab
Add Role → Custom Record Manager
✅ Save.

🧩 Restricting Access to Custom Records

Each Custom Record Type in NetSuite has its own access controls.

Step 1: Edit the Custom Record

Go to:
Customization → Lists, Records, & Fields → Record Types → Edit

Step 2: Set Access Type

Choose between:

• Use Permission List
• Use Role List
• Use Owner Restriction

Step 3: Grant Access

Step 4: Enable “Allow UI Access”

If unchecked, records can only be accessed via script — not from the UI.

🧠 Field-Level Permissions

NetSuite does not have built-in field-level security, but you can simulate it using:

1. Workflows → Hide/Disable fields based on role or status.
2. Client Scripts → Dynamically disable or hide fields on form load.

Example (Client Script):

/**
 * @NApiVersion 2.1
 * @NScriptType ClientScript
 */
define(['N/runtime'], (runtime) => {
    function pageInit() {
        const userRole = runtime.getCurrentUser().role;
        if (userRole !== 3) { // Role ID 3 = Administrator
            document.getElementById('custbody_sensitive_field').disabled = true;
        }
    }
    return { pageInit };
});

✅ This hides or locks fields for non-admin users.

⚡ Securing Script Deployments

Each Script Deployment can be limited to specific roles and audiences.

Steps:

1. Go to: Customization → Scripting → Script Deployments → Edit
2. Under Audience tab, select:
   • Specific Roles (e.g., Accountant, Admin)
   • Departments, Subsidiaries, Employees
3. Save deployment.

🔐 Tip: Avoid deploying scripts to All Roles unless necessary.

🔄 Workflow Role Permissions

Workflows also respect role-based restrictions:

• In each State Action, you can set “Execute As Role”.
• Only that role will perform the action, regardless of who triggers it.
• Use Custom Fields (Approver Role) to dynamically route records.

🧮 Example: Role-Specific Approval Workflow

Scenario:
Only Managers can approve Purchase Orders.

Setup:

• Create role: Purchase Order Approver
• Workflow condition:
  If {currentRole} = Purchase Order Approver → Show Approve Button
• Other users only see Pending state.

🧰 Troubleshooting Permission Errors

🧠 Best Practices for Role & Permission Setup

✅ DO:

• Use least privilege principle (only what’s needed).
• Group roles by function, not by person.
• Document all role changes (audit log).
• Test roles in Sandbox before production.
• Use Saved Searches for permission audits.

❌ DON’T:

• Assign Administrator roles broadly.
• Give Full Access unless absolutely necessary.
• Overlap approval and transaction edit permissions in one role.

🧮 Advanced: Script-Based Role Validation

You can restrict script execution with role checks:

define(['N/runtime', 'N/error'], (runtime, error) => {
    function execute(context) {
        const roleId = runtime.getCurrentUser().role;
        if (roleId !== 3) {
            throw error.create({
                name: 'PERMISSION_DENIED',
                message: 'You are not authorized to run this process.'
            });
        }
    }
    return { execute };
});

✅ Use this for RESTlets, Suitelets, and Map/Reduce scripts that process sensitive data.

📚 Related Tutorials

• 👉 Advanced Approval Workflows in NetSuite
• 👉 Custom GL Plug-in in NetSuite
• 👉 User Event Scripts for Record Automation

❓ FAQ

Q1. Can I restrict access to specific saved searches?
Yes — under Audience tab on the saved search record.

Q2. Can I prevent users from editing custom records?
Yes — set access level to “View” only in the Custom Record definition.

Q3. Do permissions apply to SuiteScript execution?
Yes — unless scripts use executeAsAdmin.

Q4. Can I log changes to roles or permissions?
Yes — enable System Notes v2 to track changes made to roles and permissions.

🧭 Summary

Controlling roles and permissions is the foundation of secure NetSuite customization.
By managing access at record, script, and workflow level, you can ensure users interact safely with your system — protecting data, automations, and business logic.

A well-designed role structure keeps your NetSuite environment secure, scalable, and audit-ready.