POWER BI INTEGRATION

Connect Power BI to Nmbrs

Bring the useful data from Nmbrs into one clear Power BI model. Celsius BI builds the connection, checks the definitions and delivers a dashboard your team can actually use.

FROM SOURCE TO INSIGHTLogo Nmbrs
NmbrsData modelPower BI

WHAT THE API CAN PROVIDE

Useful data, with a clear definition.

The public API can expose business data from Nmbrs, provided your account and permissions allow it. We do not copy everything blindly. We select the fields needed for decisions and retain technical keys so figures can be traced back.

The exact coverage is confirmed during an inventory. That prevents a dashboard promising data your edition, configuration or role does not make available.

01

Employees and employment

Employee, contract and employment data can support headcount, joiner, leaver and contract analysis.

02

Salary and wage components

Salary data and wage components provide a basis for labour-cost analysis when the user is authorised for this sensitive data.

03

Hours, leave and absence

Hours, schedules, leave and absence can feed capacity and absence insights.

04

Organisation structure

Departments, functions, cost centres, companies and payroll runs can place figures in the right organisational structure.

FOR AN SME

Dashboards that answer everyday questions.

Useful reporting starts with a decision, not a chart. Together we define which question the owner, commercial team or operations team needs answered and which source fields support it.

Depending on how you use Nmbrs, a Power BI dashboard could cover:

  • Headcount and FTE by company, department or cost centre
  • Joiners, leavers and contract development
  • Labour costs and wage components by period
  • Leave and absence trends within agreed privacy boundaries
  • Hours and capacity compared with planning

We define every KPI, including filters, dates and exceptions. This keeps a monthly total in the management report equal to the detail behind it.

HOW CELSIUS BI BUILDS IT

Not a loose export, but a maintainable data flow.

We retrieve data through the available API, store it in a controlled data layer and transform it into a model for Power BI. Checks catch missing pages, changed fields and unexpected totals before they become management information.

This combines data engineering with dashboarding. Our approach stays practical: start with a clear question, show working results early and document what goes live.

01

Reliable extraction

Authentication, pagination and refresh logic are handled outside the report. Power BI receives prepared tables instead of repeatedly solving the API connection itself.

02

One consistent model

Technical records become understandable dimensions and facts. Dates, statuses and relationships are normalised so measures remain reusable.

03

Reporting with context

The dashboard includes definitions, sensible filters and drill-downs. Users can move from a headline KPI to the underlying records without competing spreadsheets.

WHAT IT TAKES

From introduction to handover in five clear steps.

The scope depends on your questions and the condition of the source data. The sequence stays recognisable.

  1. 01

    Introduction

    We discuss decisions, current reports, users and pain points. The result is a limited first scope with clear success criteria.

  2. 02

    API access

    You arrange an account or app with the required read permissions. We verify authentication, available objects and practical limits without requesting broader access than needed.

  3. 03

    Data model

    We retrieve sample and historical data, map relationships and define measures. Reconciliation with Nmbrs is part of this step.

  4. 04

    Dashboard

    We build the first useful pages, review them with real users and refine navigation, filters and explanations.

  5. 05

    Handover

    Refresh, monitoring, definitions and ownership are documented. Your team receives an explanation and agreements for maintenance and future changes.

COMMON PITFALLS

The connection is only as good as its controls.

Nmbrs contains personal and salary information. Access should therefore be minimal and auditable; not every dashboard needs employee-level detail. The REST API uses OAuth and a separate subscription key. Lists are paginated, and a valid user may still lack access to a specific company. The older SOAP API is being retired towards 2027, so new integrations should use the current REST API.

Historical data deserves a separate decision. Some APIs mainly expose current state, while a useful trend requires snapshots or retained changes. We test totals against the source and record known exclusions. If a field is unreliable, we say so rather than hiding the issue in a visual.

Maintenance is part of the design too. API keys can expire, permissions can change and a supplier can alter fields or versions. We therefore document which checks run with each refresh, who receives an alert and how recovery works. We also make a deliberate choice between full and incremental refreshes. This limits load on the source and allows a failed run to catch up without retrieving all history again. Finally, we test recognisable periods and exceptions: a credit invoice, deleted record, empty value or changed status. Those cases determine whether users trust the dashboard when everyday practice differs from the ideal process.

PRACTICAL QUESTIONS

Clear answers about
Power BI and Nmbrs.

How do you handle privacy-sensitive Nmbrs data?

We retrieve only fields needed for the agreed KPIs, restrict access and show aggregated outcomes where possible. Roles, retention and detail level are agreed in advance.

Which data from Nmbrs can be used?

That depends on the API, your subscription, enabled modules and granted permissions. We start with a field inventory and retrieve only what the agreed dashboard needs.

Does Power BI connect directly to Nmbrs?

For a quick test that may be possible, but a maintained data layer is usually safer. It handles pagination, history, checks and refresh failures before data reaches Power BI.

How often can the dashboard refresh?

We choose a schedule that fits the business need and the API limits. Not every KPI needs live data; a controlled daily or intraday refresh is often more reliable.

Who owns the model and dashboard?

We document the data flow, definitions and refresh process and agree the handover. You know what is running and what is needed to maintain or extend it.

A GOOD CONVERSATION IS THE FIRST STEP.

Where are you
getting stuck?

Tell me which insights you need and how you currently use Nmbrs. We will quickly establish what is feasible and what a sensible first step looks like.

Floris Moest talking with a team working on laptops
Have a chat with Floris.About your business. And what could work better.