Last reviewed: 10 October 2026. Product details reflect this review date. Availability and behavior can vary by account, role and release.
Editorial ink illustration: An analyst compares a spreadsheet-style result with its supporting records.
A regional sales chart changes after someone adjusts a date filter. A customer pivot changes too, even though nobody edited that pivot. The two views may be using the same dataset.
In SuiteAnalytics Workbook, the dataset defines the analytical data through selected fields and filters. The workbook presents that data through visualizations such as tables, pivots, and charts. A dataset can support more than one visualization and more than one workbook. That reuse is valuable, but it also means a source change can reach further than the chart currently open on your screen.
This lesson explains how to trace a visualization to its dataset, assess a proposed change, and check the result. The aim is to make an analysis understandable before it becomes part of a management decision.
Suppose a manager asks, “Can we see sales by region?” There are at least two decisions inside the request. First, what does sales mean: orders, invoices, quantities, or another measure? Second, how should that measure be displayed?
A bar chart answers the display question. It cannot decide which transactions belong in the source or which amount should be counted. Those choices need to be explicit in the dataset and the visualization’s own analysis settings.
Begin with a plain-language definition: “This view compares the agreed invoice measure across regions for the selected period.” Then identify the record population, dates, statuses, currency basis, and role context needed to support it. If those are unclear, changing colors or adding a trend line will not resolve the uncertainty.
You can describe the two layers simply: the dataset determines which analytical ingredients are available; the visualization determines how those ingredients are arranged and summarized. Review both when a result surprises you.
Use the workbook’s dataset connection to identify the source behind the particular visualization. A workbook can contain views based on different datasets, so inspecting one tab does not establish the source for every other tab.
Record the dataset name, owner, main record context, important fields, and filters relevant to the question. Then inspect a small amount of detail. Ask what a row represents and whether the selected measure belongs at that level.
A dataset containing transaction line detail needs different reasoning from a dataset that represents one transaction per row. A customer name repeated across rows may be entirely appropriate. The important question is whether each row carries a separate item amount or repeats a value associated with the whole transaction.
The transaction search lesson introduces this row-reading habit with one invoice. Workbook uses its own analytics data source, so do not assume a similarly named field behaves exactly like a field in a saved search. Reconcile the actual fields used in the workbook.
Imagine a fictional sales team has a shared dataset for its agreed invoice measure. A regional chart uses it to compare territories. A customer pivot uses it to examine the same population by customer.
The dataset currently includes two reporting periods. The regional manager wants a single-period view. If the dataset owner narrows the shared dataset’s date filter, the change affects the visualizations that depend on that dataset. The customer pivot now has a narrower source population too.
The pivot is not necessarily broken. It is answering a question using a changed dataset. The problem arises if its title, audience, or expected purpose still implies two periods.
Before changing the shared source, ask whether the request is specific to one analysis or intended for every dependent view. A visualization-level analysis adjustment and a dataset-level change have different reach. The exact available controls depend on the view and account, so check the current configuration rather than assuming every filter sits in the same place.
If the work is exploratory, use an approved separate version where appropriate, with a clear name and owner. Do not quietly repurpose a shared operational dataset to answer a one-off question.
Only a dataset’s owner or a user with the Analytics Administrator permission can edit or delete that dataset. Having access to a shared workbook does not automatically grant the right to change its underlying shared source.
If you need a new field or a different population, send the dataset owner a bounded request. Include the business question, the field or filter you need, the current limitation, and an example that would show success. Also explain whether the change should affect everyone using the dataset.
A useful request might say: “The regional chart needs the approved one-month comparison. Please confirm whether this should use a separate analysis or change the shared reporting population. The customer pivot still needs the two-period view.” That gives the owner a dependency decision to make, rather than a vague request to “fix analytics.”
Access to records also matters. Review the intended audience’s experience instead of assuming the creator’s data visibility represents every reader. The roles and permissions access review guide provides a wider method for testing real tasks with appropriate access.
Adding related data can change the number of rows. For example, an organization can have several related contacts. If the chosen relationship returns each contact alongside an invoice measure, the invoice may appear repeatedly. Summing a repeated value would count more than the intended business event.
A join therefore deserves a small before-and-after test. Save the row count and total for a known sample. Add one relationship or field. Inspect the resulting detail before aggregating it. If the count changes, explain exactly why.
Suppose your training example contains one invoice for 100 currency units and two related contact matches. A result showing 100 beside each contact does not create 200 of invoicing. It creates two rows carrying the same invoice-level amount. That is an original arithmetic illustration of a possible one-to-many problem, not a claim that every contact join produces this output.
Joining record types within a dataset and linking datasets for an analysis are different operations. Neither should be treated as a generic way to attach arbitrary columns without checking relationships. Also avoid assuming every dataset-link definition can be edited through the current Workbook interface; confirm support for the particular operation before planning the change.
Start with detail you can recognize. Confirm a few records that should be included and at least one that should be excluded. Check the date and status that place each record inside or outside the intended population.
Next, inspect the grouping. A blank region, an outdated customer classification, or a different grouping field can redistribute a correct total into unexpected categories. If two bars change but the overall total stays constant, investigate classification before looking for missing transactions.
Finally, examine the aggregation and currency basis. Confirm what is summed or counted, whether a measure repeats, and how any conversion is handled. A chart with a plausible grand total can still hide incorrectly allocated categories.
Write the reconciliation in ordinary language: “The sample includes these three invoices, excludes this outside-period invoice, and uses one agreed currency basis.” That is stronger evidence than “the chart looks right.” It also gives future reviewers a quick way to repeat the check after a change.
When two views disagree, compare their datasets first. If they share the same dataset, compare view-specific filters, groupings, measures, and refresh context. If they use different datasets, compare the underlying populations before assuming the display is at fault.
When a newly added field changes a total, return to the known sample and inspect the join. When a user cannot edit the dataset, check ownership and authorized permissions. When a field expected from a saved search is unavailable, investigate the analytics data source instead of promising identical field coverage.
For slow analyses, retain a small reproducible case. The NetSuite performance investigation workflow helps separate observation from assumptions. Avoid repeatedly replacing working views without learning which change caused the issue.
A useful shared dataset has a stable purpose, an accountable owner, and enough explanation for another analyst to use it correctly. Keep those definitions in the team’s reporting guidance. Include the intended row meaning, key scope decisions, measures, known limitations, and dependent business uses.
Before accepting a change, confirm:
CuriousRubik’s NetSuite training services can help teams practice this review on approved examples. The next step is to apply the same discipline to dashboard KPI definitions, where a small displayed number can conceal a much larger reporting decision.