Reading Time: 3 minutes

Requirement: To set up a Custom Transaction type in NetSuite. When a user views, creates or edits a record of that custom transaction type, perform some custom action based on the permissions or access level that user role has on that custom transaction type.

Observations: This kind of requirement is very simple and straightforward if we are talking about custom records. However, when dealing with Custom Transaction types, the behavior in NetSuite changes. It is currently not possible to get the correct access level of a role on a custom transaction type record by directly using the SuiteScript 2.0 API. The user.getPermission() API will return zero if used to check the permission on a custom transaction.

Here’s an example.

I created a Custom Transaction type – Journal Type Accrual. The rest of the configuration isn’t important. This behavior is not specific to Journal type custom transactions. All three types of customs transactions exhibit the same behavior.

Under the permissions subtab, I selected a few different roles and assigned them different access levels.

As an Administrator, I should have full access to this custom transaction type. This is evident when I use user.getPermission() and the returned value is 4.
Note: When using SuiteScript 2.0 to query the permission on a record type, you have to use the numeric Internal ID and not the custom ID you set. The internal ID of the custom transaction type here is 112.

The 13: US Consultant role has EDIT access to this Custom Transaction. If I switch my role to 13: US Consultant, and run the same script in the debugger, my execution log should show a value 3. But the actual returned value is 0 (zero)!

Workaround: Create a custom record to serve as a permission placeholder for the custom transaction. This custom record will be used solely to set role permissions on the custom transaction. Instead of trying to query the permissions directly from the custom transaction, get the permission from the custom record. This does add an extra custom record that will need to be managed, but it solves the problem of not being able to correctly read permissions from a custom transaction.

Notice how the permission on the custom transaction is still zero, but the placeholder record now shows us the correct permission level.