NetSuite’s RESTlets allow you to share any structured data with Tulip. 

However, in order to set up a RESTlet, you must use multiple layers within NetSuite. And, you must be familiar with a few pre-configured functions from NetSuite.

This guide will show you how to build a NetSuite-Tulip integration that pulls in inventory and work order data from NetSuite. It will cover some common patterns that can benefit any Tulip user looking to build a NetSuite integration.

Here is the scenario:

  1. Employees have a list of work orders that are assigned to them in NetSuite. When they start their day, you want them to be able to choose a work order that is assigned to them in a Tulip app.
  2. After they choose a work order, you want to share a series of relevant data, like 10+ fields of detail on the work order. 
  3. When they press a button to review work instructions, the app will route them to the appropriate set of instructions based on data from the work order.
  4. When they complete the work order, they should be sent back to the original screen to choose another work order.

Here’s a quick diagram to how the operator’s experience in a Tulip app:


Here’s an example of the “Choose A Work Order” step.

And here’s an example of the “Work Order details” step:

This is a one-way data transfer. Although Tulip will be storing data that originated in NetSuite, no new data will be stored in NetSuite. 

From a technical perspective, this means:

  1. Upon opening the app, Tulip will query an API endpoint from NetSuite using the employee ID of the operator that is logged into the app.
  2. NetSuite will return the 6 most recent work orders that have been assigned to that employee.
  3. The operator is automatically assigned the most recent work order out of the 6.
  4. Tulip will query a NetSuite API endpoint with the work order number.
  5. NetSuite will return relevant work order details.
  6. When the operator presses complete to indicate that they have finished the work order, return to step 1.

In order to use this tutorial, you must be a NetSuite administrator with some JavaScript experience. Also, you must be familiar with the basics of Tulip’s Connectors.

Here are two resources to learn more:

Configuring Your NetSuite Permissions

Before you start creating your first script, you need to make sure a few things are set up properly.

First of all, if you want to populate a dynamic list of work orders for each operator using the Tulip app, operators must have an account in Tulip and an account in NetSuite.

After creating a user account in NetSuite, each operator will receive a unique employee ID. You can use the badge ID field in the user record in Tulip to add this employee ID. Here is an example:

In this case, the employee’s ID number in NetSuite is “6”.

Then, as the NetSuite administrator, you must ensure that you have sufficient permissions to use the RESTlet service. Every API call from Tulip will need to come from a NetSuite user with sufficient permissions. We recommend that all API calls use one NetSuite user’s credentials for authentication.

To see if you have sufficient permissions, click the “Setup” menu, then the “Users/Roles” tab, then select “Manage Users”.

Select your user account from the resulting list, and within the account, scroll down to the bottom of the page to see your Roles. Select one of the Roles, and ensure it has the correct permissions in the list at the bottom of the page.

Use this guide from NetSuite to learn which types of API calls require permissions.

Setting Up The Script In NetSuite

Before you get into actual scripts in NetSuite, you should define which data points you need to pull into Tulip. 

Let’s use an example of the work order list by operator. Here’s a reminder of what you want the operator UI to show:

For each work order that is assigned to the operator, you need to pull:

  1. The ID from NetSuite
  2. The work order number
  3. The class of the product described in the work order
  4. The end date

Here’s an example of the script you might create in order to pull the values of those fields:

function getRecordByEmployee(datain) {

 var columns = new Array();

 columns[0] = new nlobjSearchColumn('enddate')
   .setSort(true);
 columns[1] = new nlobjSearchColumn('status');
 columns[2] = new nlobjSearchColumn('tranid');
 columns[3] = new nlobjSearchColumn('custbody_assignto');
 columns[4] = new nlobjSearchColumn('trandate');
 columns[5] = new nlobjSearchColumn('class');

 var filters = new Array();

 filters[0] = new nlobjSearchFilter(
   'custbody_assignto',  
   null,
   'is',
   datain.id,
   null
 );

 filters[1] = new nlobjSearchFilter(
   'mainline',
   null,
   'is',
   'T'
 );

 return nlapiSearchRecord(
   'workOrder',
   null,
   filters,
   columns
 );

}



A few things you will notice:

  • All code is wrapped up in a single function that you define, in this case “getRecordByEmployee”
  • The function takes one parameter, datain, which you will define in Tulip later
  • The nlapiSearchRecord and nlobjSearchColumn functions are defined in the SuiteScript documentation

So, this function takes in an employee ID, searches NetSuite’s work order object for all work orders related to that ID, and returns an array of work orders with 7 key/value pairs. You will eventually include 4 of them in the app.

Now you need to deploy and test the script in NetSuite. 

Go to the “File Cabinet” in the Documents tab.

Go to the SuiteScripts folder, and upload the .js file via the “Add File” button.

Then go to the “Customization” tab in the menu bar, select “Scripting”, “Scripts” and “New”.

Start typing the name of the file you just uploaded in the “Script File” input, and when the desired script appears, click “Create Script Record”

Select “RESTlet” from the next menu.

You should be on the “Script” page. Give the script an easily identifiable name, and then define the “Get” function. This is the function that will run when you send a GET request to a specific API endpoint.

Since your script only has one function, add the name of that function in the GET field.

Then click “Save” at the bottom of the page. 

After this, NetSuite will create a new API endpoint that you can use to test and implement this function. It is shown on the “Script Deployment” page.

This shares a “Deploy” value and a script number (544) in this case. You will need these in a minute.

Open up a REST client to test the endpoint. Popular examples are Insomnia and Postman.

Then, add the URL and parameters at the end. Make sure to test with an employee ID number that actually exists in your NetSuite instance!

Then, your REST client will create the GET query and return data upon success, or report failure with an error code. The data should appear as an array full of objects with 7 key/value pairs, in this case.

Setting Up The Connector Function

Now, you need to create a Connector function in Tulip that can send query to the specified API endpoint, receive the data, and store it in Tulip.

First, create an HTTP Connector for your NetSuite instance. Use this guide if you have never created a Connector before. Here are some examples of the details:

Then, you will need to create a function within that Connector. It takes one argument- the badge ID of the operator using the app. So, make sure you have added a badge ID to each operator’s profile in Tulip before proceeding. This will be a string.

Then, add a series of outputs, which are strings in this example. They will store the results of the GET request, and allow them to be sent to a variable in the App Builder later. 

Here is an example with three data points- ID, TranID and end date- from each of the 5 most recent work orders that were assigned to the operator.

Then, in the “Query” section, add the endpoint that you just created. 

After that, add your query parameters, including the script number, the deploy number and the id, which you will need to access all work orders from a certain employee. This should be the input that you just created.

Finally, you need to map key/value pairs from objects in the array that is returned in the response to the GET request. In this case, the response is an array with 5 objects. Here’s what the mapping might look like:

In the “Path” column, add the index from the array in the response plus the key of the property you would like to map.

In the workOrderZeroID output, you would like pull in the value of the “id” property of the first object in the array. So, you use “0.id” to access the “id” property of the object at the zero index.

Calling the Connector Function in a Trigger

Now you can store Netsuite data in Tulip variables. All you need to do is to create the Triggers that will determine when to run the Connector function.

Let’s return to our app example. You want to populate a series of work orders based on the operator that is using the app.

In order to do this, you should create a “step trigger”- a trigger that fires when a step is opened. You can call the connector function from this trigger. Here’s what it might look like:

Here is what is happening in this trigger:

  • The Trigger fires “when step is opened”
  • In the first “Then” statement, you refer to the function called “get Work Orders by EmployeeID” within the NetSuite Connector.
  • This function requires an employee ID, which you include as the “Badge ID” from “App Info”.
  • The result gets saved in a variable called “workOrderEmp”, which is an object with key/value pairs that correspond to the outputs from the function.

In this case, we have a second “Then” statement because operators are only supposed to work on the most recent work order. So, when the step opens, you want to automatically store the latest work order as the one they will be working on.

Alternatively, you could add a “Start WO” button next to each row in the table, and dynamically update the workOrderID variable based on the work order chosen by the operator.

When the operator presses the “Start WO” button, the second NetSuite connector function runs and populates the following step with all the relevant details about the work order. 

Here’s what that step looks like:

And here’s the button Trigger that populates the step:

It takes the workOrderID variable from the previous step as an input, and saves all outputs as key/value pairs in a variable called workOrder.

So, to summarize, here is the order of events that lead to NetSuite data being successfully added to a Tulip app.

  1. In the Tulip Player, operator presses a button to start the app
  2. A trigger fires when the first step is opened. That Trigger calls a Connector function called “get Work Orders for Employee” with an argument of the badge ID from the active operator.
  3. The Connector function hits an API endpoint that you created in NetSuite, and returns an array with the 5 most recent work orders for that employee, with 4 key/value pairs for each object in the array.
  4. Those values are stored in “Outputs” that you manually created.
  5. In the “Then” statement of the Trigger, you include all “Outputs” as key/value pairs in one variable called “workOrderEmp”, which is an object. Then they can be accessed in an app.

Here’s what that looks like from the software side:

In this diagram, the lightning bolt icon indicates variables and properties that were mentioned in the Trigger above.

Displaying The Data In A Step

Now you have the data from NetSuite available in a variable named workOrderEmp. You just need to add it to a step to make it actionable for an operator.

workOrderEmp is an object with about 20 key/value pairs. In order to share this information in a step, you just need to use text that shares the value of a variable. You can do this in the Toolbar.

In fact, most of the “Select A Work Order” step is made of text with variable values. Here is the step in the App Builder:

There are 24 examples of text with variable values. The “Start WO” button runs a second Connector function and sends the operator to a “Work Order Details” step, which has a similar pattern to this step- 20+ different text fields with variable values.

The most complicated parts of the NetSuite-Tulip integration involve tracking and storing values as they are passed back and forth between the two software platforms. This happens across multiple tools- the App Builder, the Connectors page and 3 different parts of NetSuite.

If you have further questions about this integration, use the chat pane in the bottom right of your screen. And check out this guide to HTTP connectors if you would like to get more familiar with building Connector functions.

Did this answer your question?