Reporting & BI Studio

Reporting & BI Studio is the analytics layer of Nashua 360: the place where operational data from across the suite becomes governed reports, live dashboards and answered questions. It owns the problem that every enterprise faces once its processes are digitised, namely that the truth about the business is scattered across finance, operations, sales and service systems, locked in transactional stores that are optimised for recording work rather than for interpreting it. The Studio consolidates that data into a dedicated analytics store, applies a shared semantic layer so that a term like revenue or open ticket means the same thing everywhere, and hands users a self-service canvas for building exactly the view they need.

It sits at the top of the suite as a horizontal capability rather than a departmental tool. Every other module feeds it, and every role consumes from it, from a warehouse supervisor watching a throughput dashboard to a finance controller reconciling a margin report to an executive reviewing a board pack assembled automatically the night before a meeting.

What the Studio does

Reporting & BI Studio combines a custom report builder, a library of chart and dashboard widgets, scheduled delivery and full drill-through on governed data. The report builder is a visual, drag-and-drop environment: users choose a subject area, pull in the fields they need, apply filters, grouping and sorting, and add calculated measures without writing code, while power users drop to a SQL surface when they want it. Results render as tabular reports, pivots, or any of a broad widget set including bar, line, area and combination charts, gauges, funnels, geographic maps, heat maps, waterfalls and single-value key figure tiles.

Dashboards assemble those widgets onto responsive canvases with global filters, parameter controls and cross-widget interactivity, so that clicking a region on one chart refilters the rest of the page. Scheduled delivery sends any report or dashboard as a formatted PDF, spreadsheet or embedded link to individuals, roles or distribution lists on a calendar or event trigger. Alert-driven subscriptions fire only when a threshold is breached. Throughout, drill-through lets a user move from a summary figure down to the contributing rows and, from there, straight into the originating record in its source module.

The domain and data model

The Studio organises analytics around a handful of durable ideas. The first is the subject area: a curated, business-friendly view of one part of the enterprise, such as sales orders, inventory movements or service performance, presented in the vocabulary people actually use rather than the shape of the underlying tables. Subject areas are built on a shared semantic layer that defines every metric once, with its formula, its unit, its allowed aggregations and the dimensions along which it may be sliced. Because a measure such as gross margin is defined centrally, every report that references it agrees, and definitions cannot silently drift between teams.

The second idea is the dimension, the descriptive axis along which figures are analysed: time, organisation, product, customer, location and so on. Dimensions carry hierarchies, so a user can move from year to quarter to day, or from region to site to team, and the numbers roll up and break down consistently. The third is the analytical asset itself, the report or dashboard, which is a saved, versioned and permissioned object with an owner, an audience and a refresh behaviour. These assets draw from a dedicated analytics store kept continuously in step with the operational modules, so that heavy queries never contend with live transaction processing. Data lineage threads through all of it: any figure can be traced back through its metric definition and its source feed to the record that produced it, which is what makes the numbers trustworthy enough to act on.

BI Studio analyticsstoreFinance & AccountingInventory & WarehouseSales & CRMService ManagementHuman ResourcesProcurement
Governed data from every module flows into the analytics store that powers the Studio.

Principal workflows

A typical cycle begins with an analyst opening a subject area and composing a report against governed fields, previewing results as the definition takes shape and then saving it into a shared folder with access controls attached. From there the report becomes a building block: it is pinned to a dashboard, referenced by other reports, or scheduled for delivery. Business users rarely build from scratch; they open a published dashboard, adjust its filters and parameters to their own context, and bookmark that personalised view for reuse.

Distribution is the second major workflow. An owner configures a subscription, choosing the format, the recipients, the cadence and any conditional trigger, and the Studio renders and delivers each run without manual effort. When a delivered figure prompts a question, the recipient follows the drill-through path from the summary into detail and onward into the source module to investigate or act. The third workflow is governance: administrators certify trusted reports, manage folder and row-level permissions, retire stale assets and review usage analytics that show which reports are consumed, which are dormant and where query load concentrates. Version history on every asset means a definition change is auditable and reversible.

Functional depth that matters

Analytical correctness is where a reporting tool earns its standing, and the Studio is precise about it. Aggregation is measure-aware: additive figures sum across every dimension, while semi-additive figures such as stock on hand or account balance sum across most dimensions but take a period-end or period-average value across time, and non-additive ratios are always recomputed from their components rather than averaged, which prevents the classic error of averaging percentages. Currency-denominated measures respect a defined conversion policy, translating at the appropriate historical or period rate and reporting in a stated presentation currency, so consolidated figures across entities are sound.

Time intelligence is first-class: period-to-date, prior-period and same-period-last-year comparisons, rolling windows and fiscal calendars that need not align to the Gregorian year. Statistical treatments include moving averages, growth rates, contribution and variance analysis, ranking and percentile banding. Row-level security filters data by the viewer's identity and role, so two people can open the same report and each see only the records they are entitled to, with the restriction applied at query time rather than by hiding results afterward. Null handling, division-by-zero guards, and explicit treatment of late-arriving and restated data keep results honest. Every figure is reconcilable to source, and certified reports carry a visible trust marker so consumers know which numbers are governed and which are exploratory.

How it fits the Nashua 360 suite

Reporting & BI Studio is fed by the whole platform. It draws order, invoice and ledger data from Finance and Accounting, stock positions and movements from Inventory and Warehouse Management, pipeline and quota data from Sales and CRM, case and SLA metrics from Service Management, headcount and cost data from Human Resources, and spend and supplier performance from Procurement. Because all of these share the suite's common master data, a customer, a product or a cost centre resolves to one entity across every report, and cross-module analysis such as revenue against fulfilment cost or service load against staffing is native rather than a stitching exercise.

The Studio also gives back. Its widgets embed directly into the home dashboards and record pages of other modules, so a sales manager sees pipeline analytics inside CRM and a controller sees variance charts inside Finance without leaving their workspace. Identity, roles and permissions come from the suite's central access model, and the Automation and Workflow module can trigger report generation or react to an analytical alert, closing the loop between insight and action.

How AI Workers operate inside it

AI Workers are first-class users of the Studio and interact with governed data through the same semantic layer and security model as people. A user can ask a question in plain language, such as which regions missed their margin target last quarter, and the Worker resolves it against certified metrics, returns the figure with the chart that best expresses it, and cites the lineage so the answer is checkable. Because the Worker queries through the semantic layer, its answers agree with the dashboards built on the same definitions.

Beyond answering, Workers act. They build and schedule reports on request, extract structured figures from delivered documents and inbound spreadsheets, and monitor live data streams for anomalies and threshold breaches, raising an exception with context and a recommended next step rather than a bare alert. They provide decision support by surfacing drivers behind a movement, comparing scenarios and drafting the narrative commentary that accompanies a management pack. Within suite workflows a Worker serves as a review or approval node: it validates that a reported figure reconciles to source before a board pack is released, flags a variance that exceeds tolerance for human sign-off, and records its assessment in the audit trail. Every action a Worker takes is bound by the same row-level security and certification rules that govern human access, so nothing it reads or writes falls outside the governed perimeter.