You know which daily working decision the view, filters and detail should support.
Dashboard development (this service)OXIAE / SOFTWARE DEVELOPMENT
Dashboard development for your team.
A dashboard that shows the right information at the right time.
Discuss your projectA dashboard question: where do you start?
You first need to define the business questions, indicators and model behind the reporting.
Business intelligence consulting →Your question starts with shared KPIs, trends and exceptions for management discussions.
Management dashboard →UNDERSTAND THE SERVICE
What should you build when you need a dashboard?
A useful dashboard connects a specific question with an overview, suitable filters and the details a person needs to act. I work with you to define what belongs on the screen, where the information comes from and how to check whether the display is correct. An operational dashboard might help a team decide which open enquiries need attention. Processing can remain in your existing system; the dashboard does not need to become another business application.
When it is a good fit
This fits when colleagues repeatedly gather the same information or an existing report lacks the required combination of overview and detail. We choose one work question and check whether existing software features can already answer it. If the questions or definitions are unclear, business intelligence consulting can come first.
When to take a different approach
A periodic export or existing report may be enough for an occasional question. A dashboard does not automatically resolve missing source data or conflicting definitions; data integration may be needed first. Shared management indicators and a regular review process belong within the scope of a management dashboard.
PRACTICAL DECISION GUIDE
Start a dashboard with the decision it supports
A dashboard should help someone see what needs attention. We first define the question, useful comparison and action following an exception. An operational view of overdue tasks needs different detail and freshness from a monthly management trend. [1]
Each metric then gets a definition, source, period and refresh point. Filters must not silently change its meaning. Users can trace back to underlying records where appropriate. A visibly stale dataset is more useful than an apparently current number with an unknown update time. [2][3]
Questions to settle first
- Which decision follows when a user sees an exception?
- Does the number need minute-level, daily or closed-period freshness?
Make acceptance measurable
- A glossary defining sources and calculations for each key metric.
- Reconciliation of dashboard totals with source data for the same period.
Illustrative dashboard design — not a client case study
Which open enquiries need attention now?
A team wants to allocate enquiries without combining separate exports first. This example explains what the initial dashboard view must mean; it contains no client data or measured result.
Define what open means
The team agrees which source statuses count. Completed and withdrawn enquiries are excluded. For each enquiry ID, only the source version considered current under the agreed rules is included; the same enquiry counts once.
Make filters and time understandable
Users can see the selected team, statuses and date field. An enquiry's age uses the agreed received date; a later source update does not silently make the enquiry younger.
Connect the overview to details
A summary card and the list below it use the same selection and snapshot time. The list shows the fields needed for allocation and follow-up. Where access permits, the user can open the enquiry record in its source system.
Show an outage as an outage
When the source cannot be refreshed, the screen does not show a reassuring zero. It displays the error and last successful processing time. Whether the previous snapshot is still useful depends on the agreed freshness requirements.
What the process delivers
The user can see which enquiries meet the selected definition and where follow-up takes place. The dashboard helps assess the work; it does not independently change an enquiry's status.
How to test this example
- Closing an enquiry in the source removes it from the open selection after a successful refresh.
- A source outage remains distinguishable from a genuinely empty worklist.
- A user with a more limited role cannot reveal extra information through details or exports.
Compare your options
Choose based on the task, the people involved and what you can maintain.
| Approach | Useful when | What to consider |
|---|---|---|
| An existing software report | The software already provides the figures, filters and permissions you need. | Check definitions, export options and freshness before commissioning additional software. |
| A custom dashboard | Users need a focused combination of sources, filters and underlying details. | Calculations, source refreshes, permissions and operation need to be designed alongside the screen. |
| Define the information question first | Teams mean different things by the same indicator or have not agreed which decision the display should support. | Agreeing definitions and examples first prevents an attractive screen from presenting incomparable figures. |
What I need to start
- A user and a specific decision: what should someone be able to determine after viewing the dashboard?
- Representative source records, including closed, duplicate and incomplete enquiries; only information needed for design and testing.
- A definition, source, date field and included statuses for every indicator. Missing values and corrections also need an agreed meaning.
- Agreed filters, detail views, any exports and the roles permitted to use them.
- An agreed refresh schedule, a recognisable source-outage state and an owner for definitions, errors and maintenance.
How to assess the result
- A user can answer the agreed work question and trace a summary to its underlying source records.
- A summary card and its detail view use the same definition, filters and snapshot time; differences from the source are explained.
- Zero, missing information and a failed refresh appear as distinct states. The last successful processing time remains visible.
- Users see only the agreed information, including direct detail requests and exports; hiding information on screen alone is insufficient.
- Handover documents calculations, sources, refreshes, access control and what the operator should do after a failure or changed definition.
SCOPE & INVESTMENT
What determines the cost?
A useful estimate starts with the scope. I distinguish development work from recurring usage and operating costs. These are the main drivers:
- The number of screens, user roles, filters, detail views and exports.
- Source availability and quality, required calculations and any integrations.
- Required freshness, data volume and agreements on availability and recovery.
- An initial focused screen has a different scope from several audiences with their own definitions. Hosting, licences, operation and further development are agreed separately.
APPLICATION AND SCOPE
Your challenge.
A practical application.
Illustrative scenario; not a published client case.
A team manually gathers figures before each operational meeting.
A dashboard displays information, but first needs reliable sources and consistent definitions. Data integration brings those sources together. A business intelligence consultant helps define the questions, calculations and filters the dashboard should support before its display is designed.
THE QUESTION I ASK FIRST
Which decision should the dashboard support?
Agree the first step
Use the prerequisites, acceptance checks and cost factors above to define your assignment. Agree who can approve the outcome and who will maintain the solution. The project approach explains discovery, delivery and handover.
Read the project approachQUESTIONS ABOUT THIS SERVICE
Your questions.
Clear answers.
Does a dashboard always need real-time data?
No. Information needs to be current enough for the decision. A controlled snapshot may suit a periodic meeting, while daily follow-up may require more frequent refreshes. We show when the source was last processed successfully and what the user can rely on during an outage.
Why can a dashboard differ from an export?
Different snapshot times, included statuses, date filters or duplicate-handling rules can change the result. We compare the same source selection and period and document the calculation. Matching totals alone do not prove that the underlying records are correct.
Can the dashboard work with our existing software?
That depends on supported access, available fields, permissions and licences. The dashboard can display information and link to a source record while processing remains in the existing application. Missing technical connections may require an API integration within the agreed scope.
Sources and technical basis
These primary sources explain the technical principles behind this guide. The project recommendations are OXIAE’s interpretation; they do not imply endorsement by the publishers. Product documentation applies to the named platform.
- Tips for designing a great Power BI dashboardMicrosoft Learn
Practical considerations for dashboard audience and content.
Link and relevance checked: - Understand star schema and the importance for Power BIMicrosoft Learn
Meaning of data granularity and semantic models.
Link and relevance checked: - Data on the Web Best PracticesW3C
Principles for data provenance and quality.
Link and relevance checked:
YOUR NEXT STEP
Prepare your project conversation.
Exploring Dashboard development? Use the project checklist to describe your task, systems and intended outcome. Collect open questions and download a brief for your conversation.
Create your project brief