Rollout in progress B2B · Enterprise SaaS ERP · Portal 3.0 Self-serve analytics

Self-serve ERP analytics, without the report queue.

Seven business roles now compose their own answers from live ERP data, instead of filing a report request and waiting on the team.

Some data and figures altered to respect client confidentiality.

7
ROLES
SERVED BY ONE SYSTEM
Domain-gated
INVALID QUERIES
CAN'T BE BUILT
In rollout
PORTAL 3.0
2024 → 2025
Lead
PRODUCT DESIGNER
BUILDER · DASHBOARDS · MIGRATION
Role-based KPI dashboard with widgets and a global date filter
What we built A self-serve analytics system. Roles land on the KPIs that matter to them and build dashboards without filing a report request.

Prefer the long version? The full process case study lives at the detailed write-up.

01 · The Problem

The data existed. Access to it didn't scale.

The ERP held orders, inventory, sales, accounting, finance and purchasing data. Reporting was static tables.

Every non-standard question became a report request routed through the team. Operators waited, or decided blind. The bottleneck was the queue, not the chart library.

02 · What I Designed

A system people compose, not more reports.

A self-serve widget and dashboard builder inside Portal 3.0. You build a widget through a guided sequence, then arrange widgets into a dashboard. Each role also gets a default view already scoped to their job.

I also migrated the legacy Sales Summary and Sales Breakdown screens into the new module as system dashboards, so operators kept the views they trusted while the builder rolled out alongside them.

03 · Key Design Decisions

Constrain the path, so it can't produce a broken answer.

Domain is the gate

Domain → Measures → Dimensions → Filters → Visualization. Each step narrows the next one. That way the system can't assemble a broken combination in the first place, which beats letting people write free-form queries that fail.

Progressive disclosure over one dense form

More clicks for analysts, far higher completion for the non-analyst roles this module is actually for.

Disable, don't error

Options that don't apply never show up at all. Cheaper than explaining an error afterwards.

Role-based defaults, derived from the BRD

I translated the permission matrix into a default dashboard per audience, with admin-configurable visibility.

Migration as the adoption bridge

The legacy screens shipped inside the new module first. Operators already trusted those, and that trust carried over.

04 · Ownership

What I owned, and what I didn't.

I owned

  • Widget-builder interaction model
  • Domain-gated guided sequence
  • Role-based default views
  • Migration of the legacy KPI screens
  • Design documentation and permission-matrix translation

I did not own

  • BRD authoring and requirements (BA)
  • Data layer, query performance, RBAC implementation
  • Engineering build and deployment
05 · Final Experience

Build → Compose → Consume.

Step 1

Build

Create a widget through the guided sequence. Domain gates every downstream field, so an invalid widget can't be assembled.

Step 2

Compose

Arrange widgets on a grid-constrained dashboard. One global date filter cascades to every widget on the board.

Step 3

Consume

Land on a view already filtered to what you are accountable for. No separate BI login, no report request.

Widget builder showing domain, measures, dimensions, filters and visualisation pickers
Build The widget builder. Each step only offers combinations the data layer can actually serve.
Dashboard composition with widgets placed on a grid layout
Compose Grid-constrained composition. Drag, resize, and one date filter across the whole board.
Role-based sales dashboard with widgets and a global date filter
Consume A role's default dashboard, showing the metrics that role actually acts on.
06 · Impact & Status

In rollout, measured against the queue.

In rollout, with Purchasing and Finance onboarded first. Adoption percentages aren't available yet, and I'd rather report none than inflate them.

Primary success metric

Reduction in report-queue dependency. Request volume before versus after, and how long it takes to get from a question to an answer.

Early qualitative signal

Operators who exported tables to Excel for weekly reviews are saving dashboards instead. Anecdotal, not yet quantified.

07 · Reflection

One system that adapts, to who's asking.

I put too much weight on chart variety at the start. Nobody needed more chart types. They needed to stop waiting in a queue.
Principle carried forward · ERP Portal 3.0