NetSuite Governance Changes – Confusion Allayed

Upcoming NetSuite governance changes have caused some consternation and confusion among the NetSuite customer community. I’ve been all over the various message boards, user group sites, and LinkedIn groups, and I’ve seen it firsthand. When I saw someone write “[this announcement] may as well have been written in Mandarin as we have no clue what it means, how it may affect us and what actions we should be taking with regards to this notification,” that was quite clearly a cry for help.

To get even more technical, another user wrote “as developers writing custom RESTlets for our users, we are still in the dark as to what exactly this means.” And another: “we use RESTlets extensively. We need to have a lot more information on this, yesterday.”

So… what do the NetSuite governance changes really mean to you?

The answer is not so simple. It depends. (Just what you wanted to hear, right?)

The notice you received from NetSuite should have told you the risk level you’ve been assigned. You’re either Low Risk, High Risk Phase 1-3, or High Risk Phase 4.

The first thing you need to know is that NetSuite may not have this right, and if you’re in the Low Risk or High Risk Phase 1-3 category, you should have your complete implementation evaluated ASAP by a certified NetSuite partner. You may have integrations in place that are not visible to NetSuite, and the NetSuite governance changes are all about how you integrate your NetSuite to other applications and systems – so your risk may be higher than what NetSuite has assigned to you.

Did you catch that? This change is all about how you integrate your NetSuite to other applications and systems. There are two ways to do integrations. One is via web services (SOAP) calls, and the second way is with RESTlet calls. Web services calls are governed, and RESTlets are not, so NetSuite is implementing this change to better balance everyone’s NetSuite environment.

Here’s the real deal: In previous releases of NetSuite, concurrency for web services and RESTlets was governed separately per user and authentication method. NetSuite 2017.2 includes changes to concurrency governance. As of this release, web services and RESTlet concurrency is additionally governed per account. The new account governance limit applies to the combined total of web services and RESTlet requests.

So… instead of two buckets, one for web services and one for RESTlets, there’s now one bucket, and web services and RESTlets are managed together as a single entity. The “concurrency” limits are for concurrent requests, so no matter which type of call is made, if you exceed the maximum number of allowed concurrent requests, your system will throw an error message.

Now things get uncomfortable (don’t shoot the messenger, please!).

In the past, you could have a bunch of concurrent RESTlet calls AND a bunch of concurrent web services calls, and they would never bump into each other. Now they will. The really tough part is that, while you can monitor your web services calls currently, you can’t monitor your RESTlet calls. That right there is why there is so much confusion and consternation over these NetSuite governance changes. You don’t know where you are – so you can’t figure out where you will end up.

I’m seeing a lot of complaining about this in the various groups I’m in, and I completely understand why. That’s why my colleagues and I are working with NetSuite customers to properly assess their risk and implement a mitigation plan as quickly as possible.

For customers assessed as Low Risk, this change will roll out with your next upgrade. High Risk Phase 1-3 customers will get the changes in late September, and High Risk Phase 4 customers are scheduled to get the changes in late October.

Which means the time to assess and mitigate is now. If you need help, we’re here for you.

About the Author:

Leave A Comment