Tableau Data Connector

Why Tableau on live NetSuite queries disappoints

Pointing a data visualisation tool straight at a live ERP is always tempting and rarely survives contact with real data volumes. The pattern is familiar: a proof of concept over a few thousand transactions looks brilliant, so the dashboard gets published to the leadership team. Then the fiscal-year filter widens, three more dashboards get built on the same connection, everyone opens them at 9am on Monday, and each visualisation issues its own query against the ERP.

Several things break at once. Query latency climbs until dashboards time out. Concurrency limits mean one heavy extract blocks another. The ERP itself slows for the people trying to enter orders, because analytics and operations are competing for the same resource. And because every dashboard author writes their own joins, "revenue" quietly means four different things in four different workbooks — someone included intercompany, someone else filtered on transaction date instead of posting period, someone forgot to exclude a subsidiary.

The fix is not a faster query. It is to stop making Tableau ask the ERP directly, and instead publish governed, pre-shaped, incrementally refreshed datasets that Tableau can read in seconds.

What ECOSIRE builds

We build a NetSuite-side extract and publishing layer, delivered as an unmanaged bundle or SDF project inside your own account, that produces the datasets your Tableau workbooks consume.

Dataset definitions as configuration

Each dataset is a configuration record, not hardcoded logic: which NetSuite records it reads, which saved search or SuiteQL query backs it, which columns are exposed, how they are named and typed for Tableau, the incremental watermark field, and its refresh schedule. Adding a dataset is a configuration exercise; changing a column name does not require a redeployment.

We build these against your actual reporting requirements — transaction lines with dimensions, sales orders and fulfilments, invoices and applied payments, GL detail by posting period and subsidiary, inventory on hand and movement, item and customer dimensions, budget versus actual, and whatever else your workbooks need. Where you already have saved searches your finance team trusts, we back the dataset with those searches so the numbers in Tableau match the numbers in NetSuite. That single decision eliminates most "why doesn't this tie?" arguments before they start.

Incremental extraction that respects governance

Extraction runs as Map/Reduce scripts. This matters: Map/Reduce yields and reschedules within NetSuite's governance model, so a large extract completes across multiple units instead of dying at a usage limit halfway through. Each dataset tracks a watermark — last modified date, internal ID or posting period — so a scheduled refresh pulls only what changed since the previous successful run. Full reloads are available on demand for a specific dataset or period range, which is what you want after a backdated correction or a period reopen.

A per-run log record captures start and end time, rows extracted, watermark before and after, and any errors, so "is the data current?" has an answer you can look up rather than guess at.

Two delivery paths

You pick per dataset. A RESTlet endpoint serves paginated, cursor-based JSON that Tableau reads via a web data connector or an intermediate loader — appropriate for smaller, frequently refreshed datasets. Or a scheduled file drop: Map/Reduce writes CSV or JSON extracts to the NetSuite File Cabinet or pushes them to your own SFTP or cloud object storage, where Tableau or your data platform picks them up on a schedule. For large fact tables the file path is almost always the right answer, and it lets Tableau extracts refresh without touching NetSuite at all.

Shaped for how Tableau actually works

Datasets are published in the star-ish shape Tableau performs well against: narrow, typed fact tables with surrogate keys, and dimension datasets for items, customers, vendors, employees, subsidiaries, departments, classes, locations and your custom segments. Dates arrive in a consistent format with the posting period exposed as its own field, because period-based reporting is the thing finance always asks for and transaction-date filtering is the thing that always breaks it. Currency is delivered as both transaction and base amounts so multi-currency and OneWorld consolidation work without workbook-level arithmetic. Amount signs and debit/credit conventions are normalised once, in the extract, rather than being re-derived by every dashboard author.

OneWorld, roles and access

Every extract runs under a NetSuite role we define with the minimum permissions the datasets need — read access to the records in scope and nothing more. For OneWorld accounts, subsidiary is a first-class field on fact datasets so workbooks can filter or consolidate, and dataset definitions can be scoped to a subsidiary set where reporting is restricted. Row-level restrictions you enforce in NetSuite can be reflected in the extract configuration so a regional dataset genuinely contains only that region's rows.

Monitoring

Saved searches ship with the build: last successful refresh per dataset, row counts per run, failed runs, and datasets whose watermark has not advanced within an expected window. Failure notification goes to the addresses you nominate, so a silently stale dashboard becomes an alert rather than a discovery in a board meeting.

Who this is for

Organisations already standardised on Tableau that need NetSuite data in it reliably — finance teams building management reporting on GL and AR/AP detail, operations teams reporting on fulfilment and inventory, and analytics teams whose direct-connection dashboards have hit a performance or concurrency wall. It suits OneWorld groups needing consolidated reporting across subsidiaries, and any team that has discovered their workbooks disagree with NetSuite's own reports.

If you have one small dataset and a handful of users, a direct connection may be adequate and we will say so on the scoping call rather than sell you a pipeline you do not need.

How delivery works

1. Scoping call. We identify the workbooks and metrics you need, the NetSuite records and saved searches behind them, row volumes and growth, refresh frequency per dataset, your OneWorld and custom segment structure, where Tableau will read from, and whether you already run a data platform between the two. 2. Fixed quote. A written scope listing every dataset, its columns, its refresh cadence and its delivery path. Fixed price against that scope; extra datasets are quoted before work begins. 3. Build. We develop the dataset configuration records, Map/Reduce extractors, watermark and logging framework, RESTlet and/or file-drop delivery, the restricted extract role and the monitoring searches. Typical lead time is 2–4 weeks depending on dataset count and how much shaping each needs. 4. Install in sandbox. The bundle deploys to your sandbox first. We run every dataset, then reconcile row counts and key totals against NetSuite's own saved searches and financial reports — this is the step that earns the datasets their credibility. We connect your Tableau environment to the sandbox output and validate a real workbook end to end, including refresh duration. 5. Production. Once reconciled and signed off, we install to production, set live schedules, and monitor the first several refresh cycles with you, including a first full load and subsequent incrementals. 6. Support window. Post-go-live support covers defects, schedule tuning and column adjustments within the delivered scope.

We build the NetSuite side and prove the data lands correctly. Tableau licensing, your Tableau Server or Cloud environment and its own refresh scheduling remain yours; we work alongside them and will validate against them, and if you want workbook development as well, that is scoped and quoted separately.