Dustin Stubbs

 Need a customer name and email inside a SuiteScript? Loading the full record is the easy habit — and usually the expensive one. Use search.lookupFields when you only need a handful of values: var fields = search.lookupFields({ type: search.Type.CUSTOMER, id: customerId, columns: ['entityid', 'email'] }); var name = fields.entityid; var email = fields.email; Why it wins: Fewer governance units than record.load Faster on big records with lots of sublists Clear intent: “I only need these fields” Rule of thumb: if you’re not editing the record, don’t load it. Lookup what you need and move on.

  If you’ve been building in NetSuite for more than five minutes, you’ve hit this question: “Should I use a saved search… or SuiteQL?” Let’s make this easy. Saved Search: Your everyday hero Use a saved search when: You want something quick and easy No SQL brainpower required Admins or users might need to tweak it later You’re building reports, lists, or dashboards You want built-in sharing and scheduling Why it rocks: ☑️It’s point-and-click ☑️It’s flexible enough for most needs ☑️NetSuite optimizes it for you In short: If it’s simple (or user-facing), go saved search. SuiteQL: When things get spicy Use SuiteQL when: Your saved search starts looking like a Frankenstein You need real joins (multiple levels) You want better control + performance in scripts You’re building integrations or doing heavy data lifting You need subqueries, aggregations, or complex logic Why it rocks: SQL-style queries = more power + precision   Handles complex joins and data relationships way better Re...

Map/Reduce scripts are one of those SuiteScript features that look amazing on paper and then immediately get misused in the wild. I’ve seen Map/Reduce scripts that do everything in map , ignore reduce entirely, or blow through governance because they treat it like a scheduled script with extra steps. Let’s talk about a few real-world patterns that make Map/Reduce scripts easier to reason about, easier to debug, and much more reliable in production. This isn’t a deep dive into “what is Map/Reduce” — this is about how to actually use it day-to-day without hating your past self. First: Stop Treating Map/Reduce Like a Scheduled Script If your Map/Reduce script looks like this: function getInputData() {   return search.create({...}); } function map(context) {   // Load record   // Modify record   // Save record }   You’re not wrong , but you’re missing most of the benefits. Map/Reduce shines when: You separate read logic from write logic You group work intentiona...

Ever built a Saved Search that crawls instead of loads?  I have, and one small workaround I have found is to add &csv=Export to the end of the URL.  This will trigger the CSV export automatically.  So instead of needing to view the report and then click CSV export I can go directly to getting the CSV that I ultimately want.  Full URL will end up looking something like this:  https://[companyid].app.netsuite.com/app/common/search/searchresults.nl?searchid=1234 &csv=Export I have also used this for some external tools and Hot Key functions where I need the user to get the CSV file.

  Sometimes it's the smallest slice of a project that demands the most ingenuity. What seemed like a simple enhancement to a Saved Search ended up stretching my understanding of NetSuite’s formula logic—and my patience. 🔍 The Objective I needed to compare two types of project actions occurring within a 30-day window. Here’s the twist: Project Actions are a custom child record of a NetSuite Project (Job) , and they’re not stored in a way that makes direct comparison easy. So, I had to retrieve them through a Project Search , pulling in individual Action records via joins—first hurdle cleared. 📅 Date Math, NetSuite Style Next came the math. I needed to calculate whether one action happened within 30 days of another, but NetSuite doesn’t make date arithmetic feel intuitive. My first instinct was to use TO_NUMBER() to convert the dates into values I could compute on. Spoiler: it didn’t work. So I tried a workaround—subtracting a fixed reference date ( TO_DATE('01/01/2000...

Issue: We had a request from our Stakeholders to change a Multi-Select Field to a Single Select.  The Issue came up with this field being part of a bundle that we use.   We didn't want to deal with this being reverted or causing issues after we updated the bundle in the future, so I cam up with this work around. It is a Client Script that will throw an error to the user if they select more than one, and then it will reduce the selection to one option. /**  * @NApiVersion 2.x  * @NScriptType ClientScript  *  * 2025 Prevents multiple selections in a multi-select field * by showing an error message and removing the last selected value.  *  */ define ([ 'N/ui/message' , 'N/runtime' ], function ( message , runtime ) {     function fieldChanged ( context ) {         var scriptObj = runtime . getCurrentScript ();         var fieldName = scriptObj . getParameter ({       ...