Power BI Data Connector

The problem

Getting NetSuite data into Power BI sounds like a solved problem until you try it on a real dataset. The ODBC route needs a paid add-on and a gateway machine, and the driver's query behaviour is unpredictable enough that a refresh which took eleven minutes last week times out this week. Direct Power Query calls against NetSuite hit governance limits and pagination edge cases, and the M code that works around them becomes an unmaintainable artefact that one person understands. Saved-search exports work beautifully right up to the row cap, at which point someone starts manually stitching CSVs together.

So teams settle. The dashboard refreshes nightly if it feels like it, nobody trusts the numbers on Monday morning, and the finance team keeps a parallel spreadsheet as the real source of truth. The failure is not Power BI's and it is not NetSuite's — it is that no one built a proper extract layer between them.

What ECOSIRE builds

ECOSIRE builds a two-part solution: a SuiteScript 2.1 extract layer inside NetSuite, and a Power BI dataset modelled on top of it.

The NetSuite side

A set of RESTlets exposes governed, paginated, incremental extracts of the records and saved searches you actually report on. Each endpoint is backed by a saved search or a SuiteQL query defined during scoping, so the filtering and joins happen in NetSuite where they are cheap, not in Power Query where they are not. Every response is paged with a stable cursor, so a large extract is a sequence of predictable requests rather than one call that either succeeds or times out.

Extracts are incremental by default. A watermark stored on a configuration custom record tracks the last successfully extracted lastmodifieddate per entity, so a daily refresh pulls the delta rather than re-reading five years of transactions. A full-reload switch is available per entity for the occasions you need it — a mapping change, a backfill, a corrected historic posting.

For heavier extracts, a Map/Reduce script pre-materialises results into a staging custom record or a file in the File Cabinet on a schedule, and the RESTlet simply serves what is already computed. That moves the expensive work off the refresh path entirely, which is the single most effective fix for a refresh that keeps timing out.

Authentication is token-based (OAuth 2.0 or TBA) under an integration role you control, scoped to exactly the permissions the extracts need and no more. A read-only reporting role is part of the build.

The Power BI side

A Power Query layer consumes those endpoints and lands the data in a dimensional model rather than a pile of flat tables: fact tables for transactions, transaction lines, budgets and inventory snapshots; dimensions for accounts, items, customers, vendors, employees, subsidiaries, departments, classes, locations, custom segments and a proper date table marked as such. Relationships, hierarchies, sort-by columns and data categories are configured so slicing behaves the way a report author expects.

A DAX measure library covers the finance and operations basics you would otherwise rebuild in every report: revenue, COGS, gross margin, opening and closing balances, AR and AP ageing buckets, DSO, inventory value and turns, and time intelligence — prior period, prior year, year to date, rolling twelve months — built against the date dimension rather than improvised per visual. Row-level security can map Power BI users to subsidiaries, departments or locations where you need it.

Starter report pages ship with the model so there is something to look at on day one, but the deliverable is the model. Your analysts build on top of it.

Refresh and observability

Incremental refresh policies are configured in the dataset so Power BI only requests the partitions that changed. An extract log custom record in NetSuite records each request, row count, duration and watermark movement, so when someone asks why a figure looks wrong you can see whether the data arrived, when, and how much of it. Failed extracts raise a saved-search email alert.

Who this is for

NetSuite customers who want Power BI as their reporting layer and have hit refresh reliability, row-count or licensing walls. It suits OneWorld accounts consolidating several subsidiaries, businesses that want NetSuite data blended with non-NetSuite sources in one model, and teams whose analysts are comfortable in Power BI but should not have to become NetSuite integration specialists. If you need near-real-time data rather than scheduled refreshes, say so at scoping — that changes the extract design and the cadence.

How delivery works

1. Scoping call. We establish which reports and questions the model must answer, then work backwards to the records, saved searches, fields and custom segments required. We check your subsidiary structure, accounting periods, custom segment usage and data volumes, and confirm your Power BI setup — Pro or Premium, whether a gateway exists, who publishes. You get a written scope listing every entity, field and measure.

2. Fixed quote. Fixed price and delivery window against that scope, normally one working week depending on entity count and how much of the measure library is in play. Nothing begins until you approve.

3. Build. RESTlets and scripts are developed in your sandbox as an SDF project; the Power BI model is built against sandbox extracts.

4. Install in test, then production. The bundle installs into sandbox, and we validate the model by reconciling it to NetSuite's own reports — trial balance, income statement, AR ageing — so the numbers are proven equal before anyone builds a dashboard on them. Once you sign off, the bundle installs in production, the dataset is repointed, and the refresh schedule is set to a cadence your data volumes can genuinely sustain.

5. Support. A defect-fix window after go-live, full documentation of every endpoint and measure, and a working session with your analysts covering how to extend the model and add an entity. You own the SuiteScript source and the .pbix; there is no runtime dependency on ECOSIRE.