NetSuite editions, features, accounts, and centers

Oracle NetSuite (the company) has built the NetSuite product so that clients don’t need to worry about which server their NetSuite account is running on. When a business first signs up for the service, the NetSuite sales team will size up the organization and help them choose the right package. This includes getting them on the correct server tier. A basic starter account for a smaller company typically runs on a shared application server platform so that computing resources are efficiently shared among a set of companies. However, the data that’s accessed by each is completely segregated, so each company will only ever have access to its own records. Companies that require greater performance can purchase premium server tiers, and can even request dedicated servers if the need arises. This is typically done for companies with high transaction volumes, who cannot afford to ever be slowed down by another company’s activities on a shared server account. Read the NetSuite Help page titled NetSuite Service Tiers for more on this: https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/subsect_159162378384.html.

Each NetSuite client can have access to one or more NetSuite accounts, which is a separate instance of the NetSuite system they can work in. Next, we’ll cover the different types of NetSuite accounts and how each can be used: Production, Sandbox, Development, and Release Preview.

NetSuite accounts

When an organization signs up for NetSuite, they will always start with one main Production account. They will access their account via a URL such as https://1234567.app.netsuite.com. This is where they are expected to run their business, once they’re ready to. There are other types of accounts available though, depending on their needs.

The following diagram shows the account types that are available at the time of writing:

Figure 1.1: NetSuite account types

Let’s quickly talk about each of them.

Production accounts

Most NetSuite clients have just one of these but it’s possible to ask for more under special circumstances. This is where your data will primarily live, where emails are sent and integration connections are made. For most of a client’s users, this is NetSuite as far as they are concerned. And for that reason, the data in these accounts is critical to the organization and should be treated as such.

Sandbox accounts

Think of these as temporary accounts where customizations or any sort of testing can occur, without causing any problems for the production data. NetSuite sells these individually for an extra fee. Sandboxes are refreshed from the Production account on an as-needed basis and, when that occurs, they then have a separate database reflecting the changes that were made in the Sandbox account. One way to move things from a Sandbox’s configuration to a Production account is via the Copy to Account feature, which we’ll talk a bit about in Chapter 18, Managing Gaps and Creating Custom Automations.

One other big difference with Sandbox accounts is that they don’t send emails to their intended addressee. Instead, they are redirected either to a set of named users or to the NetSuite user who was logged in when the email was generated. Otherwise, NetSuite cannot send emails at all.

Development accounts

With each Sandbox a client purchases, NetSuite provides three additional accounts of this type. They have a separate database as well, but they are never refreshed from Production. Instead, they are used just to develop standalone customizations that can then be deployed into any of the other accounts for testing or production use.

These Development accounts can be very helpful for companies who think of their development like a SuiteApp partner would, where they’re building standalone customization. For almost any other purpose, they can be more trouble than they’re worth since they can’t automatically get data from Production and you have to manually set up everything you want in them, such as bundles and other customizations.

Release Preview accounts

Just before NetSuite’s biannual major updates are released, the company offers each client a copy of their Production account for advanced testing of the new features.

Each NetSuite client must request their Release Preview (RP) account to be set up, but there is no additional fee for this service.

These RP accounts only last for a few weeks though, just enough time to test new features and confirm that existing configurations and customizations will continue to operate as expected.

Work with your NetSuite account manager whenever you want to make a change to any of a client’s accounts.

Data in NetSuite accounts

NetSuite maintains daily internal backups of every account. However, no client should ever assume that the backup is going to be there to cover any mistakes they might make or, worse, to recover from failed experiments. Instead, a carefully planned data management approach is needed. Most clients can run their accounts for years without any incidents, so they won’t need to restore a backup, which is largely different from most on-premises software applications. This is because NetSuite (the company) takes such care to make sure the application runs without errors or other things causing any harm to the data. There are, however, many ways a client or users can cause issues themselves. For instance, NetSuite includes two features known as CSV Import and Mass Updates, which are very powerful but also very dangerous if they’re used incorrectly or carelessly.

I’ve seen more than a few cases where someone ran CSV Import and overwrote important data incorrectly or inadvertently. The same goes for Mass Updates. Generally, these features are restricted to NetSuite administrators and should stay that way, but if a client gives an inexperienced user (including consultants like us) the power to use any of these powerful features, bad things can happen.

A client can contact NetSuite Support and request data to be restored, but that should be left as a last-resort option. Instead, every time anyone is thinking of making any sort of bulk update to data, or maybe changing data they’re not very familiar with, it’s a best practice to make a manual backup of that data first, via a CSV export, for instance. Nobody should rely on NetSuite to provide backups, but you may ask them in emergency cases. Just note that when NetSuite Support restores a backup, it will be the entire account; they cannot just restore one item or sales order, for instance.

This situation is mainly for the data in Production accounts, but there are times when the data in Sandbox accounts can be just as critical. In a typical implementation, we might import lists of things such as customers and items fairly early on in the project, and once those are in, we don’t want anyone erasing them or making large-scale changes without careful planning. Having to re-import a lot of data mid-way through a project can introduce unplanned delays, if not done correctly. Also, keep in mind that when a Sandbox is refreshed, all of its current data is erased/lost and replaced with the data that was found in the Production account at that time. Clients and implementation teams need to carefully review the data in the Sandbox before these refresh events, to be sure nothing important in the account is in the Production account at the same time.

Sandbox refreshes

In the life of a typical mid-sized or larger NetSuite client, when going through a typical implementation process, we usually end up following a schedule that looks something like this:

• Day 1:
  • Start to configure the Production account.
  • We’ll set up the first users, enable features, and start to choose options.
• About a month or so later:
  • Request a refresh for the first Sandbox.
  • The client usually does this once they’ve got the OK from all the teams working in the Production account.
  • This is where customizations, integrations, and data migrations will be developed and tested.
• Sometime later:
  • Request a refresh for a second Sandbox.
  • This is where UAT will happen, before going live, so this can only happen after all the elements needed for that full round of end-to-end testing have been configured or installed.
• Days before going live:
  • Deploy to Production.
  • This is when we move all the customizations, integrations, and final data for migrations into production.
  • Sandboxes cannot be refreshed in production, so we usually use other features at this time, such as suite bundles and the SuiteCloud Development Framework (SDF).
• And then we perform the other cut-over activities.

We’ll cover this in more detail later in this book, but keep this general process in mind as you continue reading. And note that this is entirely dependent on the size and complexity of the organization that’s being implemented. Many smaller companies can get through their entire implementation process with just their production account, for instance, which greatly simplifies and speeds up this process.

How NetSuite is updated

Since NetSuite runs in the cloud and not at every client’s office, it is NetSuite’s job to keep the application software up to date. Due to this, the product receives updates automatically, twice per year, typically around April and November. The first of these major updates is known as the .1 release for that year, while the second is known as .2. So, this year, at the time of writing, clients will be updated to 2023.1 in April and 2023.2 in November. These updates include both fixes for reported problems and new features and enhancements to the product.

In between these two major updates, NetSuite can also patch any part of the system via what is known as either e-fixes or hot pushes. An e-fix is a small update that’s used to fix defects reported by NetSuite clients and rolled out to the live systems only when needed. Hot pushes are fairly rare as they are emergency patches needed by one or more clients, usually to resolve a recently introduced product defect. For instance, this kind of update might be used if a problem with a major release causes issues for many clients simultaneously.

NetSuite clients cannot choose to never receive any of these updates; however, they can sometimes choose when they receive them and which of their accounts will be updated first. When this is needed, the client can work with NetSuite Support to request alternatives to the default rollout plan.

Whenever a major update is about to be released, NetSuite’s clients and their partners should start to plan for how to adapt to the new features and incorporate them into their business process. For instance, on occasion, a new feature is released that can replace a customization a client had developed in the past. When this happens, the client should evaluate the new feature, compare its setup, records used, and so on to their custom solution, and then define a plan for how the business will migrate into the now native feature (assuming that makes sense). Generally speaking, it’s usually better for a client to run with as few custom solutions as possible, so this kind of thing is usually the right choice. This is where using those Release Preview accounts mentioned earlier can be very helpful, although it’s always important to keep their temporary nature in mind. Don’t ever start a development project in a Release Preview account!

Since major updates are automatically applied to each account twice per year, nothing special ever needs to be done by the client to enable/facilitate this. The upgrade usually happens overnight (depending on where the client is); when you first sign in the next day, the account’s version number will have changed. The same goes for hot pushes, except the minor revision version number indicating a change at that level is not displayed on the home page.

At that point, conscientious clients (and partners, among others) will perform smoke testing for their main business processes to ensure that everything works as expected. It is very rare for issues to arise because of an upgrade, but it’s always better to find them via testing than to find out after a week or more that some critical function is no longer delivering the expected result.

You can find the revision number; it’s just not in an obvious place. Sign in to NetSuite, right-click the home page in your web browser, and select View Page Source. Scroll to the very end of that source listing and look for a block of text that looks like this:

<!-- Host [ abcdef ] App Version [ 2022.2.0.96 ] -->
<!-- COMPID [ 1234567 ] URL [ /s.nl ] Time [ Sun Jan 10
15:36:03 PST 2023 ] -->
<!-- Not logging slowest SQL -->
2022.2.0.96

In this example is the full version number of the account you’re looking at. That’s generally not a number anyone needs to keep track of, but now and then, it can be useful to know how to find this information.

Generally, NetSuite is very, very careful to ensure that every update they release is well tested and that it will not break any existing configuration or customization clients might have. When the company knows that a change is going to cause issues, they almost always provide many months’ advanced notice so that clients can prepare their systems and integrations to support the new approach. This is especially true for things such as integration protocols, such as SAML for single sign-on, or various features of the SuiteCloud Platform. In my 9 years of working on the product, I’ve not seen more than three or four cases personally where an update caused an issue and the client wasn’t given months of notice before the change took place.

Now that we’ve looked at what NetSuite is, let’s look at the people who work to make NetSuite the incredible product it is – and how they can help you do your job too.