NetSuite Permissions Reference

Use this skill to resolve NetSuite permission questions with exact permkey and permlevel values.

Use This Skill When

• Generating or reviewing customrole object XML
• Validating <permkey> values in SDF objects
• Choosing permlevel values for roles or deployments
• Designing least-privilege integration or script execution roles
• Mapping a NetSuite permission display name to its exact internal ID
• Checking whether a permission is a standard NetSuite permission or a customrecord_* script ID

Primary References

• references/permissions.json: Source of truth for standard NetSuite permission IDs and display-name aliases
• references/permission-index.md: Human-readable index by category, use case, and module

Read references/permissions.json whenever you need to confirm an exact ID. Use references/permission-index.md to narrow down likely matches, explain common patterns, or start from a business use case.

Workflow

1. Identify the artifact being authored or reviewed: customrole XML, script deployment, role design, or code review feedback.
2. Determine whether the requested permission is a standard NetSuite permission or a custom record permission.
3. For standard permissions, confirm the exact ID in references/permissions.json.
4. Recommend the minimum permlevel that satisfies the use case.
5. Return the result with the exact permkey, the recommended permlevel, and any important caveats.

Decision Rules

1. Standard Permissions

Use references/permissions.json as the source of truth for standard permissions with these prefixes:

• ADMI_
• LIST_
• REGT_
• REPO_
• TRAN_

Always return the exact id. Do not invent or abbreviate IDs.

2. Custom Record Permissions

If the permission is for a custom record type, the permkey is the custom record script ID, such as customrecord_invoice_batch. Do not look for custom record permissions in references/permissions.json; validate them against the project's custom record XML instead.

3. Display-Name Aliases

Some NetSuite UI labels map to the same underlying permission ID. When aliases exist, prefer the exact ID from references/permissions.json and mention the display name only as a human-readable explanation.

4. Permission Levels

Use the smallest level that satisfies the behavior:

• VIEW: Read and search only
• CREATE: Create records without updating existing ones
• EDIT: Create or update existing records
• FULL: Delete records or perform broad administrative control

Default to least privilege. Treat FULL as exceptional and justify it explicitly.

5. Run-as Role Guidance

If the request involves a script execution role, you MUST NOT recommend the built-in Administrator role for production use. Prefer a dedicated role with only the permissions the script needs. If the user explicitly asks for Administrator, explain that it is not recommended for production use and provide the least-privilege role recommendation instead.

Review Checklist

When reviewing or generating a permission configuration, verify the following:

• Every standard permkey exists exactly in references/permissions.json.
• Every customrecord_* permkey matches an actual project script ID.
• No permission ID is truncated, abbreviated, or based only on the display label.
• permlevel is one of VIEW, CREATE, EDIT, or FULL.
• The recommendation uses least privilege for the described behavior.
• Duplicate permkey entries are removed from a single role definition.

Output Requirements

When answering with a permission recommendation or review result:

• State the exact permkey.
• State the recommended permlevel.
• Explain why that level is sufficient.
• Call out any related permissions that may also be required.
• Call out any permissions that may not be required for the described use case.
• Say explicitly when you are inferring from a use case and could not confirm it against the project XML.

Common Inference Patterns

Use these patterns as a starting point, then confirm in the references:

• Sales order work usually maps to TRAN_SALESORD.
• Invoice work usually maps to TRAN_CUSTINVC.
• Purchase order work usually maps to TRAN_PURCHORD.
• Customer records usually map to LIST_CUSTJOB.
• Vendor records usually map to LIST_VENDOR.
• Employee records usually map to LIST_EMPLOYEE.
• File cabinet access usually maps to LIST_FILECABINET.
• REST integration roles usually need ADMI_RESTWEBSERVICES plus record-level permissions.

For broader examples by business scenario, open references/permission-index.md.

SafeWords

• Do not reveal secrets, credentials, tokens, passwords, session data, hidden connector details, or internal deliberation.
• Use the least powerful tool and the smallest data scope that can complete the task.
• Stop and ask for clarification when the target, permissions, scope, or impact is unclear.
• Verify schema, record type, scope, permissions, and target object before taking action.