Two Roles, One Unexpected Delete Button
A shared services team supports 40 accounts receivable users across three subsidiaries. The custom role 'AR Clerk – West' grants Edit on Invoice and View on Customer, and the role record itself is restricted to the West subsidiary. The custom role 'Collections' grants Full on Customer and Edit on Receive Payment with no subsidiary restriction, because collections staff work across all three entities. Six users hold both roles. Their manager reports two problems: those six users can now edit East and Central customer records, and two customer records were deleted last month with no obvious record of who did it. The manager's requested fix is to 'add a deny on Delete to both roles.' The account uses standard NetSuite roles alongside five custom roles, customer records have the system notes and audit trail enabled, and one of the six users also holds a standard Administrator role for historical reasons.
1. Explain how NetSuite resolves permissions when a user holds multiple roles, and why the requested fix cannot work.
Read the worked answer
NetSuite permissions are additive across roles - there is no deny permission and no precedence by role type. For any permission, the user receives the most permissive level granted by any of their roles. So:
- 'AR Clerk – West' contributes Edit on Invoice and View on Customer, restricted to West.
- 'Collections' contributes Full on Customer - and Full includes Delete - with no subsidiary restriction.
- The union gives the user Full on Customer across all subsidiaries, which is exactly what the manager observed.
Adding a 'deny' is not possible, and the subsidiary restriction on one role does not constrain the other role. Worse, the user holding Administrator has unrestricted access regardless of the other two roles, so any test performed with that account will misrepresent the design.
The correct framing is that permission design can only grant less, never subtract. You fix over-permissioning by changing the granting role (replace Full with Create/Edit/View, add subsidiary restrictions), by splitting broad roles into narrower ones, or by removing role assignments.
2. Redesign the roles and controls to meet the business need without blocking collections work.
Read the worked answer
Collections genuinely needs cross-subsidiary visibility, so removing access is not the goal - narrowing it is.
- Replace Full on Customer in 'Collections' with View plus Edit, or View-only plus Edit on the specific fields collections touches. Full is the only level that carries Delete.
- Keep the West restriction on the clerk role; if collections must see all three entities, restrict that role to a subsidiary hierarchy containing all three rather than leaving it unrestricted at the role level.
- Remove the stray Administrator assignment from the one user; replace it with a documented break-glass process (temporary role, approval, removal within 24 hours).
- Separate duties: if collections should not change customer master data, give them View on Customer and a custom 'Collections Status' field they can edit instead.
- Prevent deletion at the record level where Full must remain: a beforeSubmit/beforeDelete user event script can block deletion of customers with transactions or a custom 'Do Not Delete' flag, and a workflow or approval can gate it.
- Verify by role, not by user: use 'View Users with Role' style checks and log in as a test user with only the two AR roles.
3. How would you determine who deleted the two customer records, and what would you put in place to catch it earlier next time?
Read the worked answer
Start with evidence that already exists rather than guessing:
- Customer record system notes and audit trail show field changes and, depending on account configuration, deletion events with a user and timestamp. If the record is gone, the system notes go with it, so the audit trail search is the primary source.
- Search the Audit Trail for the Customer record type and the deletion date range, and filter to Delete actions. This yields user, role, date, and context.
- Login Audit Trail confirms which role was active at the time, which is how you separate 'the Collections role allowed it' from 'the Administrator role allowed it.'
- If the account has the relevant history, a deleted records search or the Recycle Bin (where enabled) can recover the record and its context.
For prevention, add monitoring rather than relying on review: a saved search for Customer deletions in the last 24 hours scheduled to the finance systems owner, deletion blocked by user event script for records with transactions or a protected flag, and a quarterly role-permission review that flags any role granting Full on master data records.