Dustin Stubbs

Ever run a Transaction saved search and get way more rows than you expected? You’re probably looking at line-level data without asking for it.  When I was first learning NetSuite this was an issue I ran into a few times before learning the importance of this criteria. On Sales Orders, Invoices, Bills, and friends, NetSuite stores a header and a row per line item. Leave Main Line unset and you get both; so a 10-line order can show up as 11 rows (or more, once you add tax/shipping lines). The fix: add this criteria to almost every header-focused Transaction search: Filter: Main Line Operator: is Value: True (or T in a formula / SuiteScript filter) In SuiteScript that looks like: filters: [ ['mainline', 'is', 'T'], // ...other filters ] When to leave it off: you actually need item, quantity, amount, or other line fields. Then keep Main Line = F (or omit it) and be intentional about grouping/summarizing. Rule of thumb: if you care about the doc...

 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...