NetSuite Integrations 101

Anchor Group Podcast: Episode 21

Follow Us On LinkedIn!

• Caleb Schmitz, CRO at Anchor Group
• Michael Mueller, eCommerce Account Executive at Anchor Group
• Anchor Group (Company Page)

Podcast Transcript

Caleb (00:00)
On this episode 21, we talk through integrations and what it looks like to do SuiteScript Direct API integrations from NetSuite and other software solutions. We lightly touch on an overview of middleware and the value of those. We also go into the process of SuiteApp and bundles, and why to use one scenario versus the other. If you're a software company trying to get into the NetSuite ecosystem, this is a really good conversation for you.

Or, if you have NetSuite and want to integrate to one other software system and want to know the options, there are also a lot of good topics for you.

Today, we’re talking mainly about integrations, and I want to start with an overview of the topic. We're going to focus on integrations hosted within the NetSuite environment rather than middleware. In a future episode, we'll talk more about middleware options. There are really two main approaches:

The first is an integration hosted within NetSuite. That means it's a direct API to API, which can be hosted within NetSuite or, in some cases, within the other software you’re connecting to. Not all software allows that, but NetSuite does because it's the ERP. That’s why direct API integrations—where the scripts and information are hosted within NetSuite—are common. These are generally REST APIs now, not SOAP.

The second option is middleware, which we’ll cover in more detail later. There are generalist middleware options like Celigo, iPaaS, and MindCloud, and more specific ones like Feedonomics for e-commerce or SensePass for payments. Middleware is a layer that sits between software. But today we’re focusing on direct API integrations using NetSuite specifically.

Michael (02:27)
That’s perfect, Caleb. As we dive into this topic, what are some of the most common use cases where you see businesses leveraging these types of integrations day to day?

Caleb (02:41)
NetSuite already has a lot of modules that solve many business pain points. There are also point solutions that solve things even better because they’re made for a niche scenario. It’s your business decision to determine if those point solutions are better for your needs. If they are, then you have to deal with an integration.

You don’t always have to integrate every software you use. But integrations are usually needed when you have high volumes of data or daily data transfers—more than just monthly updates. Common examples are order-to-cash processes, procure-to-pay processes, accounting data, inventory management, or managing multiple sales channels.

Let’s say you need to take a PO, extract the information, and create a sales order—maybe from a large customer. EDI is another example where different types of orders come in that way. Order management data is the most common type of integration.

For example, with Amazon, do you really want to CSV import each order into NetSuite daily or multiple times a day to fulfill them? The answer is no. That’s where integrations come in, especially with multiple channels like eBay, Walmart, and others, in addition to your own site like SuiteCommerce or BigCommerce—which would also require an integration.

Do you have any other ideas you’ve seen, Michael?

Michael (04:45)
I have a question about when you reference selling on Walmart, eBay, or Amazon. Say I’m using NetSuite and want to branch out. Am I going to need a different integration for each within NetSuite, or is there an app or feature I can get that plugs in once and broadcasts my product information to all those channels?

Caleb (05:13)
Yes—and that’s the argument for why middleware makes sense. If you’re connecting to lots of channels, you only need one integration to NetSuite, and then the middleware connects to each channel. You’re still connecting to the middleware, but integrations from those channels are often simple apps within the middleware—just a few clicks and easy configuration.

ERP integrations are more complex. There’s more data, and they’re harder to set up. By reducing the number of ERP integrations with middleware, it can make sense to have one middleware application talking to NetSuite, and then the middleware branches out to other channels.

This is why Feedonomics in the BigCommerce space makes sense. But sometimes you just have a one-time integration that’s unrelated to middleware, where very different mappings are needed. For example, a payroll integration is a different data flow to map into NetSuite, whether it’s direct API or middleware. Either way, you need to map to new records in NetSuite. That’s where direct API integrations can make sense for one-off cases.

Michael (07:10)
That’s what I’ve seen too. If a company is integrating with only one other platform—say eBay or Amazon—and they don’t plan to expand in the next few years, a direct integration makes sense.

I know we’ll get more into middleware in another episode, and I’m glad you referenced connecting to something other than a selling channel. But let me ask you: if someone is technical and understands NetSuite well, how difficult is it for them to create one of these API connections to another software within NetSuite? What does that look like?

Caleb (08:10)
Let me define “technical,” because I’ve had people who are super users call themselves technical because they can troubleshoot a script or a workflow a little bit. I would argue that although that’s semi-technical, it’s not the level of technical you need to do this. You need to know how to do SuiteScript development, which is a JavaScript-based language, and that’s the primary format. There are different types of scripts, and you can do REST calls within scripts.

If you’ve done SuiteScripting, I’m talking about more than running something in ChatGPT or another AI tool that spits out a junk script that sort of does the trick but doesn’t have a good architecture. You need to know when to use a Map/Reduce script, when to batch files, when to use a Scheduled Script or a User Event Script, and other best practices.

If you have zero exposure to what I just said and no idea what those terms mean, you’re probably not ready to build a direct API integration—it’s code, and it’s building scripts. But if someone calls themselves a NetSuite developer, they can do it.

Because of how large the NetSuite ecosystem is, it’s easy to find someone to staff or modify the work now or in the future. That’s a big advantage—it’s not specialized knowledge that only Anchor Group has. While I’d love everyone to work with us, it’s good for someone building an integration to know they have a large talent pool if they want to hire full-time later. This skill set is out there. Most NetSuite admins are not SuiteScript developers. They may know how to do administrative tasks and build workflows, but it’s a different skill set.

Michael (10:15)
Yeah, that’s an important distinction. Understanding the difference and defining what “technical” actually means is a good idea when we enter this conversation.

Caleb (10:24)
Most NetSuite customers say, “I’ll just hire a NetSuite admin who can do everything we need.” That’s not really the right perspective. People in the NetSuite ecosystem—admins, developers, or anyone experienced—hear that and think, “We’ve got a lot of expectations to correct.”

If you expect one admin to have all those skill sets and be the single resource to solve all your pain points and optimize everything, you’re in for a rude awakening. It’s definitely multiple skill sets. Most admins know this about themselves. They might do some light debugging and read code a little bit, but being both highly functional and able to write really good SuiteScript is rare. I call that being “techno-functional”—someone who’s very good at the functional side and can also write excellent SuiteScript.

Michael (11:21)
So let me ask you this: how long do you think it takes someone to become, as you said, techno-functional? Say we have someone on our team, and we want an internal resource long-term to be able to do this in the future—how long until they become dangerous with those skills?

Caleb (11:44)
On the functional side, it’s about knowing all the native processes within NetSuite and all the modules. The time it takes depends on the number of iterations you go through. To be a very good functional resource, you can’t just have been a NetSuite admin at companies—you have to be a NetSuite consultant to get the exposure and volume you need.

Two years as a functional consultant in the NetSuite space is like eight years as an admin in terms of experience and exposure. That’s a rough ballpark, but it’s in that realm. Admins who become consultants often say, “Wow, this is a whole new level,” because they’re flooded with so many use cases.

To know all the modules and native features well for good solution design—and also know SuiteScript on top of that—I’d say it takes a solid decade to become a really good techno-functional consultant. You can know some light SuiteScript and core processes like order to cash and procure to pay in less time, but you won’t know all the modules deeply along with SuiteScript without at least a decade of experience.

Michael (13:10)
That’s good perspective.

Caleb (13:10)
And I would argue probably a decade of experience in the consulting space, not as an admin.

Michael (13:14)
That’s good perspective. In consulting, you see so many different companies, and everybody’s NetSuite is set up differently, with different goals and needs. That makes sense.

Now, how long would it take—and right now we’re talking about developing something that doesn’t currently exist. We know there are pre-built things you can get, and we can get into that in a second. But if we know it’s going to take an internal team member years to figure out how to do this on their own—of course with training, but with experience being the big factor—how long would it take a consulting company, whether that’s Anchor Group or anyone else in the NetSuite ecosystem, to implement a standard, vanilla integration that doesn’t already exist?

I know that’s not a very specific question, but if we’re talking about a vanilla, standard integration—not too complex, not dealing with too many customizations, mostly native features in NetSuite—how long does that take to develop?

Caleb (14:27)
Let me clarify: it doesn’t take years for someone with light development experience to build an integration. It takes years to do it very well, to understand all the considerations and impacts to the rest of NetSuite and the ERP system. Having really good solution design and high-quality work requires that extra expertise across the functional systems.

The technical ability—if you already know development—can be picked up relatively quickly. But doing it well requires the functional knowledge to avoid downstream impacts others might not foresee.

In general, a NetSuite integration has a few phases. The first part is finalizing the solution design—looking at each of the record types. NetSuite has different record types, like a customer record, a contact record, and sales order records. Different transaction types—sales order, invoice, payment record against the invoice, cash sale associated to the sales order—are all different record types.

When you’re building an integration, you need to map the record types first, not just the fields. Field mapping can be done after outlining the core process areas. E-commerce tends to be more complicated because you have many record types.

Someone might say, “I just need items and sales orders.” I try to be respectful, but in my head I’m chuckling—you definitely need more than that. For example, in B2B ecommerce you have: A customer record, with an associated contact record. Item data, probably sourced from NetSuite and pushed to BigCommerce. Sales orders.  A cash sale for credit card purchases. Logic for terms-based customers where you create a sales order without a cash sale. Invoices sent from NetSuite to BigCommerce. Payment records returning from BigCommerce to NetSuite for reconciliation. Inventory updates after sales orders are committed.

There are many flows people don’t think about, so it’s important to spend time outlining these at the start, get full alignment, and then move to data mapping.

Once the fields are mapped, our functional consultant—who understands the business and accounting impacts—passes that success criteria to our developer. The developer then builds the scripts and creates the “handshake” between NetSuite and the other software.

End-to-end, a more complicated ecommerce integration can take around four months. A simple one—say, an item feed from NetSuite to another system—can be done in under a month in terms of level of effort, though the total project timeline depends on iterations and review cycles.

Michael (19:12)
Interesting. That’s good insight. I know NetSuite has the SuiteApp ecosystem. When we talk about these integrations, how does the SuiteApp ecosystem play into all this? Are each of those their own integration? Or how does that work?

Caleb (19:31)
SuiteApps are sometimes separate applications with an integration to NetSuite, and sometimes they’re built entirely within NetSuite. A hybrid would be a scenario where it’s integrated but also has an external component.

Before SuiteApps, there was another technique. To get a SuiteApp approved, you have to go through a pretty lengthy approval process. Oftentimes, if a software company wants to create a NetSuite integration and get into the market, I recommend not dealing with the politics of getting into that marketplace right away. It’s really just a website where your app is listed—it’s more of a marketing play than anything.

Michael (20:28)
It’s a true marketplace.

Caleb (20:30)
Right—it’s a true marketplace where people can find you. It’s like lead generation. There are other benefits: you can push updates and manage deployments, but for a software company, the biggest value is being listed so people can look up your product.

You can still accomplish the goal of having an easy-to-install NetSuite app using what’s called bundles. Bundles can be searched within a NetSuite environment. As a NetSuite user, I can look for bundles others have made, see the author, and install it if it’s public or I’ve been provisioned access.

A bundle is just a collection of fields, scripts, and records—the building blocks within NetSuite. For example, we’ve built bundles for integrations with payment processors. Those bundles impact multiple transaction types and fields. Once the bundle is built, we just install it in the customer’s NetSuite environment and establish the API connection. It’s much faster than developing from scratch.

If you’re trying to enter the NetSuite ecosystem, I almost always recommend this approach first. It gets something in the ecosystem so you can demonstrate it to NetSuite customers. We help clients—software companies that want to integrate with NetSuite—by building it, setting them up with demo environments, and guiding them through actually demoing it to their customers. That way, there’s evidence it works and is pre-built, which is important because NetSuite customers are, rightfully so, hesitant when someone just says, “Of course we do that.”

Michael (22:48)
That’s right—the proof is in the pudding. I like that idea. It’s a great way to get an MVP product out there so you can start iterating, learning, and proving the concept. If it’s high enough quality, you can start using it and update it as needed. But to clarify, if you go that route, it’s a great way to get started, but you can’t automatically push updates over time.

Michael (23:15)
And it sounds like to be in the SuiteApp ecosystem—within that marketplace—there are more requirements. Looking at a SuiteApp, you might get some assurances that these apps are managed and can push updates directly to my environment. From the merchant’s perspective, am I right in assuming that you might need less time to manage those SuiteApps if they’re from the SuiteApp environment?

Caleb (23:53)
Well, to maintain your SuiteApp credentials, you actually have to do a lot of maintenance. With a bundle, updates are manual—the end user has to click the update button in their NetSuite environment. There’s no automatic push. There’s also no required process to create a bundle, whereas a SuiteApp has a process you must follow. The way they’re built and their components are very similar.

Michael (24:32)
Yeah, and I think that’s important for people to understand—they’re genuinely very similar in how they’re built and stored. If it’s built as a bundle and someone just needs to click a couple of buttons to update it, most super users won’t find that time-consuming.

Michael (25:00)
Either option seems like it can be a good choice for merchants looking for integrations.

Caleb (25:06)
An example of maintenance for a SuiteApp: I know people who spend about a month twice a year—every NetSuite release—just running updates to keep their SuiteApp current. That’s a lot of labor just to maintain it. That’s another reason I recommend the bundle route: you can update on a case-by-case basis or for a specific customer.

Long term, a SuiteApp can make sense, but I suggest taking it in phases. Understand the ecosystem before going all in.

Michael (25:57)
Caleb, I know one thing you and I always talk about is that everybody's NetSuite ecosystem is similar, but at the same time, all of them are different. When we talk about bundles and integrations, and focus more on the pre-built integrations, how customizable are these? Let’s take a bundle example. We can create that for the average NetSuite user and environment, but if there needs to be customization, how hard or easy is it to make part of that bundle so the integration works the way it should?

Caleb (26:39)
If you're going the bundle route, during the bundling configuration you determine what fields and scripts are included. The author of the bundle can decide which elements are locked or unlocked. You can unlock a script so people can modify it, or lock it.

Let’s forget the bundle for a minute. If I’m just an end user customer of NetSuite and build a single SuiteScript without bundling it, it’s very customizable. You have full access to the code. NetSuite’s APIs are some of the most robust I’ve seen, covering many record types. We can even surface our own custom API endpoints. The only time I run into API issues, it’s with the other software we’re connecting to, not NetSuite.

Michael (27:50)
From there, are you able to throttle up or throttle down the flow volume—how quickly data flows between them? What dials or controls do you have to manage the flow of data between these platforms via the integration?

Caleb (28:11)
Flow and frequency can be set at intervals like every 15 minutes if it’s scheduled, or triggered on an event basis or via webhook. You can have a live integration in that sense. Volume is generally not an issue, though there are concurrency limits to consider when sending massive volumes of data at once.

I recommend giving priority to core operations—things like sales orders—so they consume that bandwidth first. Other integrations can be scheduled for off-hours, like the middle of the night, to avoid using up bandwidth during peak times. You can also purchase additional NetSuite licenses, called SuiteCloud Plus, which give you more “lanes on the highway” for data flow.

If you expect a rush of data—like rush hour traffic—plan your flows accordingly. Decide what needs to happen live, what can run every 15 minutes, and what can run overnight. Making those decisions early is important, because they compound over time.

Michael (29:50)
I love that analogy—lanes in the highway. It makes a lot of sense, especially for merchants preparing for heavy traffic on Black Friday or Cyber Monday. Being able to strategically manage data flow can become a superpower if you know those days will be intense.

Caleb (30:15)
Side note related to lanes on the highway: I grew up in a small town of fewer than 4,000 people with only one or two stoplights. Driving on a highway with more than two lanes was intimidating when I was learning to drive.

Michael (30:49)
It’s wild when you go from two-lane roads to driving on a five-lane interstate. Totally different experience.

Caleb (30:56)
That was pretty crazy. But I think that wraps up this episode. We covered a lot of information, and this topic can be technical and confusing for some people. Sometimes it’s easier just to talk to someone. We’ll walk them through their specific scenario—hear what they’re trying to achieve—so they don’t get lost in unrelated details.

If anyone wants to discuss integrations, I encourage them to reach out. That’s it for today. Thanks for all your questions, Michael, and we’ll see you on the next one.

Where to Listen to the Podcast

Find more episodes of the Anchor Group podcast!

• Anchor Group Podcast on Spotify
• Anchor Group Podcast on YouTube

Oracle NetSuite Alliance Partner, BigCommerce Certified Partner

As both a BigCommerce Certified Partner and an Oracle NetSuite Alliance Partner, Anchor Group is ready to handle BigCommerce and NetSuite projects alike! Whether you already have one platform and are looking to integrate the other, are considering a full-scale implementation of both platforms, or simply need support with ongoing customizations, our team is ready to help answer any questions you might have! Get in touch!