About nine years ago, I was looking to connect with other technologists in Silicon Valley who had worked with NetSuite. I realized this network didn’t exist, so I started the NetSuite User Group. Today, we have over 650 members and meet quarterly to collaborate as a community. I also co-hosted the Salesforce.com User Group many, many years ago. My passion for User Groups stems from my experience working in technology. We all have a unique lens, and when we go to work, we tend to see what’s right in front of us. Getting together in one room opens our minds and sights to a broader picture and helps us learn.
I’ve worked for three internet security companies, Qualys, Imperva, and Zscaler, as Senior Director of Enterprise Application (or Business Technology). In 2020, I decided to do something different and became the CTO and CIO of AppWrap, a NetSuite implementation consultancy.
I started out as a hardcore engineer, and for many years, I loved to build everything from the ground up. If you like to build in-house, maybe you’ve worked with the vendor-provided APIs of a given application, like NetSuite. Most developers begin custom-coding native integrations or building processes to connect systems and automate the movement of data (e.g., ETL: Extract Target and Load, Reverse ETL, etc.), but long ago, I stopped building everything from scratch. This brings me to iPaaS–Integration Platform as a Service–a topic that garnered a lot of discussion at a NetSuite User Group meetup I recently co-hosted with Workato. In the spirit of knowledge sharing, this post captures my perspective on using integration and automation to your advantage and some general best practices for working with NetSuite.
Benefits of Integrating ERP Business Systems
By virtue of working with an ERP–Enterprise Resource Planning–such as NetSuite, we technologists realize the importance of integrating our business systems. What’s not always clear is the best way to go about it, and so, an internal narrative unfurls. We may ask ourselves questions like this:
- Do I need to spend more money to do it?
- Should I invest specifically in an iPaaS?
- Do I need to deal with another vendor and implement another solution?
- Sure, I can build it, but should I when there is a good option to buy it?
Over the years, I’ve learned that it’s better to invest in a relationship with an iPaaS vendor and spend the money to get the job done. Why? The answer is you get scale, speed, and flexibility.
Scale
Scalability is the first reason I would consider using an iPaaS. They specialize in the space and have the best practices, allowing me to focus on solving the core needs of my business. Guardrails, ongoing improvements, maintenance, support, and documentation are already built into an iPaaS platform like Workato.
I know I could build my own machine to deploy something and get a project going myself. I could roll out a solution, but then as things grow, I’d have to roll out more servers, chase down bugs, address updates and patches, and manage an ongoing headache. Going with an iPaaS vendor means one less headache. I don’t need to patch the machine. I don’t need to worry about downtime. These tools automatically log issues, and an audit trail is available so you can comply with your requirements, which also applies to security.
Speed
In terms of speed, leveraging an iPaaS is a game-changer. Rapid development, rapid deployment, rapid maintenance, and suddenly, I can build and roll out things very quickly. Putting these low-code/no-code solutions in the hands of a developer (or skilled business user) gives us much more productivity and faster time to value than what our stakeholders need.
This is not to deny that a talented team of developers can build anything. I mentioned that I come from a software engineering background, so from experience, a common problem with engineers is we can build anything, but we don’t like to maintain things. So why not make it somebody else’s problem? When that Salesforce API changes and the connection breaks, I don’t have to be the one to fix it. When NetSuite changes its API, I can let my iPaaS handle it.
Consider this scenario. I built my own ETL solution and want to integrate a given API. First, I have to get access to the API. Then, I write the integration code and verify it. By building from scratch, my work grows and grows and grows. An iPaaS takes care of many hurdles. I get a cloud-based interface to connect my applications once I have all the data I need at my fingertips as pills and objects. And as new vendors, applications, and upgrades come out, I don’t have to deal with more and more companies and software.
Flexibility
I am an expert in NetSuite, but there are always other systems, right? Whether it’s another ERP part of the business is using, a CRM, Marketing tools, or an HR system like Workday, ADP, Bamboo HR, etc., they will need to be connected at some point, in some way.
Now, if we had Workato involved, they would have the depth and breadth in their platform to take care of this for us. So, when we start these in-house build projects, we must be aware of the pitfalls and always ask questions about the systems and processes we are working with. What are the known limitations?
Let’s cover some best practices for building integrations with NetSuite.
NetSuite Development Tips and Best Practices
Access
SOAP used to be the way of the world. Slowly, more and more, we see GraphQL, which is very interesting and very powerful, so you have to be aware of the pros and cons of each. Finally, the NetSuite REST API for all entities and transactions is now generally available, which is excellent. This was not the case until recently, and it’s a terrific option to work with as it’s the modern default. It opens up possibilities with SuiteQL, which is basically SQL for NetSuite, so that we can read all the data easily – powerful stuff. If you need to read NetSuite data, always use REST and SuiteQL.
Principle of Least Privilege
Always adhere to the Principle of Least Privilege when setting up your API access and never test as Administrator. That is, the user/process should only have privileges essential to performing its intended functions. If you are using a non-admin account, then you really need to make sure that it works.
Transformation
Data doesn’t necessarily fit. It’s longer, shorter, requires a value, or does not require a value in one system. Usually, business owners say “integrate,” and you are left wondering, what happens if the field is shorter? Can I truncate the value? Do I need to chop it and put the rest into a custom field? These are the things where tools won’t help. This is where you and your project manager are better off spending the time to get it right.
External IDs
Another instrumental feature we have is the NetSuite External ID. Using these external IDs allows you to perform Upserts (simplifies the integration), and you can update/identify records in NetSuite by their “original” IDs in the source system (without knowing the NetSuite Internal IDs). Of course, there are some considerations. You have to make sure that the External IDs are truly unique. And if you start an integration and some objects already have a value in their external ID, do you reset them?
Error Handling and Logging
Ideally, we have a single approach for error handling/logging in our ETL projects to allow graceful failure and notifications. Consider logging directly into NetSuite or Salesforce.com custom objects.
This is another place where Workato can help. Not only do they log and handle errors but they can trigger automations when the problems occur. If there’s an error, Workato can notify the builder. It’s not a matter of just logging into the ether; the errors are handled automatically and sent with the details needed to take swift action. This is something to think about not only for resilience but also for security and compliance.
Final Thoughts
It’s tempting to jump in and start building integrations ourselves because then we don’t have to ask for a budget, right? Wrong. When it comes to scope and ownership, people forget that there has to be someone who owns these projects long term, and at the executive level, someone has to provide the budget, even if they never need to join a meeting, receive an email, or discuss the project. Usually, it’s a sign of a great project if we haven’t had to escalate to our executive sponsor. If you never have to get them involved, that means you did your job well. Having an iPaaS tool will allow you to do your job well…and better!
