Setting up a Custom Role for a NetSuite to PBCS Integration

Firstly – this blog assumes you’ve set up a standard NetSuite to PBCS integration – please see my blog here for a step-by-step walkthrough to set up a standard integration.

There are, however, a few problems with the standard integration. It’s powered by a role in NetSuite called, intuitively, PBCS Integration. A role in NetSuite effectively acts like a Security Group in Hyperion, it grants you access to other NetSuite items. By assigning this role to a user account, you can log-in with the user account in FDMEE and power your integration through it.

However, this role is locked – so you can’t amend any of its permissions. This is a problem because:

1. It has very high-level access – in our experience we wanted to integrate time records but not financials – and our integration admin would have access to everything.
2.  It doesn’t have access to custom modules, and as it’s locked you can’t add this in

The solution to both problems is to create a custom role – but there’s an extra step that makes it slightly harder than it ought to be.

To do this, navigate to Setup > Users/Roles > Manage Roles and locate the PBCS Integration role – note the little padlock indicating it is locked. Press Customise and you will have the option to duplicate – give it any name that you like (in our case, PBCS Integration 4) and now you have an identical role which can have unnecessary access removed. We also took the extra step of ensuring the ID contained customrole_nspbcs to follow other patterns, but this might not be necessary.

However, there’s one extra step needed – because we found that switching to our custom role broke our existing integrations, which were powered by the standard role. FDMEE would give an error code of “You do not have privileges to view this page”.

Very odd, considering our custom role is exactly the same as the standard one. Switching to log level 5 revealed this helpful nugget – it was attempting to connect to a RESTlet known as a Script Deployment.

By navigating to Customization - > Scripting -> Script Deployments and finding the deployments mentioned above, we found that by default the deployment is available only to Administrators and the standard role PBCS Integration. 

We opened ours up to all roles to avoid this issue in future, safe in the knowledge that it’s still securely protected by the username and password required to obtain any data. Repeat this step for all three deployments.

Now our integrations work beautifully, and we were able to add access to our custom module to this role to power even more custom integrations with no extracts or hassle.

Want to know more about creating custom queries for integrating metadata and custom module data? There’s a blog for that too – check it out soon.

Until next time,

Mike