Start with the question, then choose the view
A useful dashboard helps someone understand what is happening and decide what to do next. Before choosing charts, identify the person using it and the question they need answered.
“Show our activity” is a broad request. “Which requests are overdue, who owns them, and which need attention today?” gives the work a clearer direction.
This guide uses dashboard in the everyday sense of a visual overview. Your finished Power BI solution may use reports, dashboards, or a combination, depending on the interaction people need.
Decide who will use it
Different audiences often need different views. A team member may need a list of assigned work. A manager may need workload by team. Leadership may need a summary over time.
Agree when each audience will look at the information, what they should notice, and what action follows. A report used in a monthly meeting may need a different level of detail and update schedule from one used to coordinate daily work.
Choose a small set of questions for the first version. Additional views can follow once the core information is useful and trusted.
Define each measure in plain language
Terms such as open, complete, overdue, and active can mean different things to different people. Write down the definition before building the calculation.
For each measure, identify what is counted, which date is used, what is excluded, and who can confirm the result. If you show a percentage, define both the numerator and denominator. If you show a target, identify who set it.
The following definitions are illustrative choices for a request tracker, not rules every organization should adopt.
| Measure | Example definition | Question to settle |
|---|---|---|
| Open requests | Distinct request IDs whose current status is New, In progress, or Awaiting review | Are paused or cancelled requests excluded? |
| Overdue requests | Open requests with a due date before the agreed reporting date | Which time zone and cutoff apply? How are missing due dates handled? |
| Completed this month | Distinct requests with a completion date in the selected calendar month | How are reopened requests and repeat completions treated? |
| Completion time | Elapsed calendar time from submission to completion for included completed requests | Should the measure instead use business hours or exclude paused periods? |
Identify where the information lives
List the systems, files, or records needed to answer the questions. For each source, record its owner, the relevant fields, how it can be accessed, and how often it is updated.
Check whether records have a reliable identifier. If one request appears on several rows, joining the data incorrectly could count it more than once. Also review missing dates, duplicate records, inconsistent status labels, and changes to department names.
A dashboard can make an information problem more visible, but a chart does not repair the source. Agree where corrections belong and who is responsible for making them.
Know what history you can actually report
A current list may tell you how many requests are open now without telling you how many were open at the end of last month. Reconstructing that history may require dated events, snapshots, or another reliable historical source.
Similarly, a completion-time measure needs usable start and finish dates. If those dates were never captured, the missing history cannot simply be calculated from today’s status.
Identify these gaps early. The first phase may include improving how information is collected.
Choose how current the information needs to be
Agree how old the information can be before it stops being useful. Consider both when the source is updated and when the reporting solution receives those updates.
Power BI refresh behavior depends on the connection and data model. Connecting to a source does not automatically make a report real-time. Some sources may also need an approved gateway or other connectivity setup.
Show a clear “data as of” or last successful refresh indication where appropriate, and agree who responds if updates fail. A refreshed report can still contain old information if the source has not changed.
Plan who can see what
Identify who can view summaries, inspect individual records, export information, or edit the reporting solution. Consider whether teams should see only their own records and whether names or other detailed information are necessary.
Power BI can restrict access to rows of data, but that protection depends on the configuration and the user’s permissions. A filter on the screen is not an access-control boundary. Test with representative users, including what each person must not be able to see.
Power BI’s Publish to web feature makes content publicly accessible. It is unsuitable for confidential business or personal information; use an appropriate controlled-sharing method instead.
Match the display to the question
Use a trend when the question is about change over time, a comparison when it is about differences, and a clear list when someone needs to act on specific records.
Include readable labels, units, dates, and filter context. Do not rely on color alone to communicate a status. Keep the most useful information prominent and test the experience on the devices people will actually use.
A compact summary with a useful detail view is often easier to work with than a page filled with charts.
Agree how the result will be checked
Choose a small set of records whose expected results can be checked independently. Compare totals, exclusions, date boundaries, duplicates, and missing values against the agreed definitions.
For example, if the sample contains 24 distinct open requests and 6 meet the agreed overdue rule, the overdue count should be 6. If a percentage is needed, 6 divided by 24 is 25%. These are fictional validation numbers, not business results.
Ask the intended users whether the report answers their questions and supports the next action. Agree who accepts the first version and how later changes to measures will be handled.
Plan ownership and ongoing costs
Identify who maintains the sources, updates access, monitors refresh, and answers questions about the measures. Keep a short definition guide so the meaning of a number is not lost when people change roles.
Sharing arrangements, licenses, capacity, data preparation, and connectivity can affect operating costs. Solvency Studio’s development, training, and support fees are separate from software costs. These requirements belong in the scope before the solution is built.
What to bring to a first conversation
Bring the questions you want answered, the people who need the answers, and an example of your current report or process. Note the likely data sources, important definitions, access restrictions, and how often information needs to change.
Use anonymized or fictional examples for an initial discussion; do not send sensitive records through the public inquiry form. “We do not know yet” is a useful starting point for any unresolved item.
Solvency Studio can help turn these details into a reporting plan, including data preparation or specialist input where needed.