The quick answer
Create the role from the Role page, add the required permission at the appropriate level, save it, and assign it from the employee record’s Access subtab. The saved assignment confirms the role is associated with the employee, but it doesn’t test login or downstream access.
The screenshots show sample data. Person and operating-company names are fictional. Use your own records and values when following the steps.
Before you start
You need permission to manage roles and edit employee access. The employee must already exist and be eligible for NetSuite access, and you should know the role name, required permissions, access levels, subsidiary scope, and any authentication restrictions.
01. Check the new Role form
Confirm that the Role form is open before entering any values. The form includes the required Name field and permission sections such as Transactions, Reports, Lists, and Setup. Review any applicable center, subsidiary, restriction, and authentication settings shown against the access design you intend to use.
02. Enter the role and permission
Enter the approved role name in the required Name field. In the applicable permissions section, add the required permission and set its access level; the recorded example shows Find Transaction at View. A View permission applies only to that permission and doesn’t provide read-only access to every transaction.
03. Save the role definition
Review the permission row and the role settings, then select Save. Saving creates the role definition; it doesn’t test the role through an employee login or prove access to every page and record. Continue only after checking that the selected permission and level match the intended design. Reopen the saved role to confirm its name and permission row before relying on the assignment.
04. Open the employee Access subtab
Open the existing employee record in edit mode and select Access. Confirm that the employee is configured for NetSuite access before changing the assigned roles. The recorded employee form shows Access alongside the other employee subtabs. Confirm Give Access or the equivalent login setting is enabled; enable it only as authorized for this employee.
05. Assign the role and save the employee
In the Access area, select the newly created role in Role and click Add and review the row before selecting Save. Save the employee record to persist the assignment. The saved relationship changes the employee’s assigned roles, but it doesn’t establish that the employee has logged in or that all expected pages are available.
Check the result
- The role definition contains the intended role name and the required permission at the intended access level.
- The employee record displays the custom role in the assigned Roles list after the employee record is saved.
- No conclusion is drawn about successful login or complete downstream access until the role is tested separately under the employee’s account and configuration.
Common questions
How do I create a custom role with a View permission?
An administrator or authorized role administrator creates a role, enters a name, adds the required permission under the appropriate permissions category, and sets its level to View. A View permission applies only to that specific permission; it does not provide read-only access to every transaction or record.
How do I assign the custom role to an employee?
Edit the existing employee record, open the Access subtab, confirm the employee is eligible for NetSuite access, add the custom role to the roles list, and save the employee record. The available fields and role options can vary by account configuration, enabled features, and the administrator's permissions.
Where can I confirm that the role was assigned?
Reopen the employee record and inspect the Access subtab's roles list. Seeing the custom role there confirms that the assignment was saved, but it does not confirm successful login or access to every page the employee may need.
Why might the employee still have limited access?
Effective access can be affected by subsidiaries, employee or record restrictions, authentication settings, feature availability, the employee's other roles, and account-specific configuration. Saving the role and assigning it does not test the employee's login or prove access to a particular record or page.