Developing for NetSuite — Our road through HackWeek’s Goals Management Bot

Introduction

ServiceRocket is known for its Grow the Tree program, allowing the company to be strong and provide more to everyone by Sharing the fruit. One of its approaches to accomplish this are NetSuite Goals, which are a set of goals each quarter for the continuous improvement of people, their teams, and their ways of working. It’s not rare that sometimes, a team gets organized to work on the same goal, or goals, which helps the team build stronger relationships, better teamwork, and many other benefits.

Having shared goals could be nice in many ways, but it also has some issues in how teams collaborate to complete these goals, for example, updating and sharing their status with the rest of the team, reporting and commenting on them, managing and monitoring them, etc. This process is error-prone and time-consuming, besides, each member of the team has to do these tasks every week for their own goal.

During the 2022 Hack Week, the RAD Squad worked on the idea of simplifying the management of goals for a team through a simple but powerful chatbot for Workplace which will enable you with the ability to build a team, create a ‘Shared Goal’, and assign a driver that will update status every week for the rest of the team, so everyone is aware of its status without using third-party tools. This article is intended to go through our journey and highlight some of the issues we ran into while developing on NetSuite.

The Goals Management Workplace chatbot

One of the main things we needed for the project was a Workplace chatbot, which, the team already had experience in building, so this was the easier part of the whole project. The team was split so we could have progress on both sides, one being the work in the chatbot and the other, the NetSuite scripts to manipulate the data.

First, we focused on the commands that would be available to be used with the bot, commands like creating the goal for the tagged people, getting the status of the goal, commenting on the goal, and modifying the status of the goal for everyone, which were the actions that we usually have to do manually on NetSuite.

The second part of the chatbot was to link the commands we made with NetSuite to do the things that the commands were intended to do. At first, because the NetSuite part wasn’t ready at the time of development we made dummy calls with hardcoded data to simulate the NetSuite scripts behaviors so we could keep developing without blockers. After the NetSuite scripts were ready we just had to replace the dummy data and calls with the actual endpoints for the scripts.

Enabling the chatbot’s NetSuite connection

NetSuite doesn’t seem to have a direct API to manage things granularly like goals, but it allows the creation of scripts to extract, create and modify data. While searching through NetSuite’s documentation on how to interact with records like goals, we found two types of scripts, which were SuiteScripts and RESTlet scripts.

SuiteScripts is a NetSuite’s platform built on JavaScript that acts like a library that is available on most parts of the site, if not every part of it. It enables the customization and automation of processes allowing access and manipulation of business records and user information via scripts that are executed at pre-defined events. For example, page access, field change, form submission, before read, before write, etc. They can also be scheduled to run at specific times.

RESTLet scripts are server-side deployed scripts that interact with NetSuite data following RESTful principles. RESTlets extend the SuiteScript API to allow custom integrations with NetSuite. They offer ease of adoption for developers familiar with SuiteScript and support more behaviors than SOAP-based web services, which are limited to those defined as SOAP web services operations.

With these scripts, we would be able to create, read and update the content of the goals, and even add more detailed logic to the scripts to fit our needs.

Dealing with SuiteScripts

We started our development for NetSuite with SuiteScripts because it was the first type of scripts that we found information about, and because the documentation was somewhat decent for the basics. When we found out about RESTLets we decided to keep experimenting with SuiteScripts mainly because they use the same syntax and it was easier to test due to SuiteScripts running on the NetSuite’s site directly while the user was logged in.

Here is where things started to get a bit difficult. We were able to read certain records on NetSuite, like Contacts, User information, Events, etc… but the records related to goals were failing when the scripts were executed. We didn’t know why.

var receivedGoal = record.load({
  type: record.Type.GOAL,
  id: goal.id,
});

While we were working on this issue, someone else was investigating about RESTLet scripts, because we knew at this point that we would need them to be able to integrate the chatbot with the NetSuite scripts on behalf of the user, and besides, it uses the same syntax as ScriptLets. At some point, someone decided to try the code we already had, but with the RESTLet script he was developing, and to our surprise, it worked without any problems.

Some of the documentation:

SuiteScript Developer & Reference Guide

SuiteScript Overview

Getting Started with RESTlets

For protecting the available endpoints NetSuite offers three types of authentication:

• Three-Step TBA Authorization Flow which offers a redirection-based authorization flow with token-based authentication where users enter their credentials into one of the following login forms as a part of the flow: A trusted NetSuite login form; SAML SSO identity provider’s login form; OIDC OP provider’s login form.
• OAuth 2.0 which is based on the authorization code grant flow for the generation of access tokens and refresh tokens, or the client credentials flow. These alternatives are more straightforward than the three-step TBA authorization flow, because they do not require the signing of requests.
• Using User Credentials with which you can authenticate by providing a user ID and password. With this approach, you use an NLAuth authorization header. NLAuth is a NetSuite-specific authentication approach that is used for RESTlets only.

Connecting the chatbot with NetSuite

Given the three ways of securing the endpoints, we opted for OAuth, mainly because it's one of the most common ways of authentication.

The first step was to make an endpoint available so we could link a workplace user to a NetSuite user. This is where OAuth 2.0 method comes into place. You can check more information about how to achieve this in the documentation.

After obtaining and storing the required tokens for the NetSuite connection, we just had to use them to request access tokens so the bot could act on behalf of the user and authenticate them for the API calls to the RESTLet scripts.

Now that we had the authentication problem sorted out, we just had to bind the chatbot commands to the functions that would manage the logic to, for example, create goals for each user, making calls to the NetSuite RESTLet on behalf of each one of the users involved.

To conclude

NetSuite offers a big degree of freedom when it comes to customization, allowing you to control most things in detail thanks to their JavaScript API, making it possible to automate simple tasks to the more complex ones, and even integrate your own apps into it.

Working with NetSuite’s JavaScript API was a challenge, especially because finding the right documentation was a bit difficult, and then, understand it and making it work was another obstacle that we had to overcome, but once we got the hang of it, everything else became a lot easier.

As always, the better the documentation on a system, the easier it gets to work with it and achieve the desired outcome.