16.2 Building Roles Instead of Sharing Administrator

Build a role the company controls

Use a custom role for daily work. The Administrator role already has every permission at every level, including setup, Full CSV Export, and delete. A custom role receives Administrator-only tasks only when you add them on purpose, such as Core Administration Permissions.

Standard roles cannot be modified. Customize, at Setup > Users/Roles > Manage Roles, creates a custom role that starts with the standard permissions. You change those lines and assign the custom role, which you can still edit after people use it. Manage Roles > New starts with no permissions: name the role and select Center Type, which fills default permissions you then edit. Customizing a standard role keeps that role's center. Parent Role, when the record shows it, names the standard role you copied. To duplicate a role, change the name and choose Save As.

Standard roles can change in a release. Help states that updates to the default role are not pushed to custom copies. You edit the custom role yourself when you want a permission the standard role gained. Enabling a feature does not add that feature's permissions to custom roles that already exist. Since the 2025.1 release, permissions on some standard roles were updated, including Employee Center, Partner Center, Vendor Center, and Customer Center. A custom role based on one of them can still show the old lines as unsupported. Those lines stay until you change the custom role. Owning the custom role is how the company decides when access changes. The cost is a review after each release and after each feature you enable.

Create or customize a role for anyone whose access you expect to adjust. Keep Administrator for account administration, and give it to as few people as the account can run with.

Center Type is set only at creation

Center Type cannot be changed when you edit an existing custom role. Help states that after you create and save a custom role, you cannot change the center assigned to it. A custom center can be assigned only on a new role: go to Setup > Users/Roles > Manage Roles > New, choose Center Type, and save. Customizing a standard role keeps that role's center. If the saved role has the wrong center, create a new role, set Center Type, and move users. You cannot fix the center on the saved role.

The locked setting is Center Type. The other three choices in this contrast stay editable.

Inactive can be changed later. Inactivating a role is ordinary maintenance.

Employee restrictions can change on an existing custom role. The edit page includes subsidiary restrictions, employee restrictions, and department, class, and location restrictions, plus permissions, forms, searches, and preferences. After you save, users log out and back in so the new restriction applies.

Two-factor authentication can change as well. The role stores Two-Factor Authentication Required and Duration of Trusted Device, and an administrator can also update roles at Setup > Users/Roles > Two-Factor Authentication Roles. The default trusted-device duration is Per session. Administrator and other highly privileged roles require two-factor authentication, separate from the Center Type lock. Web services and SuiteAnalytics Connect roles cannot require it.

Inactive, employee restrictions, and the two-factor authentication setting remain editable. Center Type does not.

Which permissions are especially sensitive

Control sensitive data by leaving it off the role. A restriction hides rows of a record type the role is allowed to open. It does not replace a permission you should never have granted. Help's standard-role guidance is to give only the access the job needs. Add a permission when a test login shows the job cannot be done without it.

Administrator-only capabilities. Skip Administrator for daily work. Core Administration Permissions can give a role some functions that otherwise belong only to Administrator, such as an IT administrator who maintains the account and should not see sensitive employee information. Use caution: that role becomes similar to Administrator for those privileges. The older Full Access role is deprecated.

Mass delete. A mass delete requires the Mass Updates permission and the level Help lists for that record. At Lists > Mass Update > Mass Updates, the user picks a delete such as Delete Events. Delete Cases and Delete Events require Full on Cases and Events. Delete Files requires at least Edit on Documents and Files, and those files cannot be recovered. Full on a record permission also deletes individual records of that type. A data-entry role should not have Mass Updates, and it should not have Full on records the user must never remove.

CSV import and export. Import CSV File and Export Lists are separate. Full CSV Export stays with Administrator. A role copied from a standard role may already include one of the CSV lines. Remove it unless that job loads or extracts files. A downloaded file is no longer filtered by subsidiary, department, class, location, or employee restrictions.

Accounts and employee compensation. The Accounts permission opens the account list. Department and class restrictions do not hide accounts with those fields blank, so Accounts plus a department restriction still shows unassigned accounts. Restricting accounts requires limits on the account records and on the role.

Employee Compensation, with Advanced Employee Permissions enabled, is the permission for compensation information. It is meant for managers, defaults to View with a Subordinates restriction, and you can change both. It ignores the general employee restrictions on the role page. The Lists permission Employees is wider: it gives full employee-record access and takes precedence over the advanced employee permissions. Remove Employees when the role should not see every field. Payroll and commissions stay hidden from Allow Viewing and from Allow Cross-Subsidiary Record Viewing.

How to test the control

Assign the custom role to a test employee, log out, and log in as that employee in the custom role. If you add the role to your own user, log out and return in that role. Do not judge the design while you are still Administrator. Administrator holds every permission, global permissions do not apply to it, and that session will not show what the custom role hides.

On that login, confirm three layers. At Create, you can add a record and open an existing one, and you cannot save a change to the existing one. A subsidiary, department, class, location, or employee limit hides records outside its scope, and User Subsidiary shows only the subsidiary on the test employee. Import CSV File, Export Lists, compensation fields, and Delete Events under Mass Updates should be missing unless the job needs them. A blank-department account stays visible when the role has Accounts.

If the test employee can do something extra, remove the permission or tighten the restriction, save, and log in again. Someone already signed in will not see the change until that logout. Role searches and Show Role Differences (Setup > Users/Roles > Show Role Differences) show whether the custom role drifted from the standard role you copied. Repeat the test login after a release or a new feature, because custom roles do not pick up those permission changes on their own.

Practice the level, the restriction, and the test login in the Oracle NetSuite Foundation practice questions.