User Access, Roles, and Permissions
This domain tests identity and access design: employee and user records, role-based permissions, restriction dimensions, authentication, and access review. Expect scenario questions about least privilege and why a user can see or act on a record.
Roles and permission levels
- A role bundles permissions and restrictions. Users can hold multiple roles; NetSuite combines access, and restrictions are typically applied most restrictively.
- Permission levels include View, Create, Edit, and Full. Actions such as approve, delete, or run are often separate permissions; Full on a record does not automatically include approval.
- Role restrictions can limit by subsidiary, department, class, location, employee, and IP address. A user's employee record can add restrictions.
- Authentication controls include password policy, MFA, SAML SSO, OAuth 2.0, and token-based authentication. Login Audit Trail records access.
Worked example
An AP clerk must enter vendor bills for one subsidiary but must not pay vendors or approve bills. Reasoning: create a custom role with Vendor View and Bills View/Create/Edit, omit Bill Payment and approval-related permissions, restrict the role to the target subsidiary, assign it to the clerk's user, and verify with a test login. Do not copy an AP Supervisor role and remove permissions blindly; review every dependent action.
Traps
- Administrator is a role, not a person; sharing it defeats segregation of duties.
- Inactivating an employee does not always remove access; check the user record and assigned roles.
- Subsidiary restrictions on the role and on the employee can stack.
- Full permission on a transaction does not guarantee approval rights.