A CRM dashboard is useful when each number has a clear definition, the right people can see it and a named owner can act on it. Start with the business question and the underlying record set. Then test filters, dates, permissions and the route from a chart to the records that explain it.
An attractive chart can conceal different meanings. “Open pipeline” might include a different set of records from “opportunities created this month”, and a won total is not necessarily a conversion rate. Write the population and time basis beside the metric before discussing colours or layout.
The original metric card below creates a repeatable review of one proposed dashboard. Odoo’s Pipeline Analysis and Microsoft’s Power BI embedding documentation provide concrete examples of defaults and access conditions that deserve deliberate checks.
Which decision should each dashboard view support?
Begin with a question such as “Which open enquiries need an owner?” or “Which completed opportunities were won or lost?” Name the person who will act on the result. A view without a clear decision can become a decorative report that people inspect without knowing what to do next.
For every metric, record the unit counted, included states, excluded states, date field and scope. Specify whether the date means creation, expected closure or actual closure. If the dashboard compares periods, write how a record enters each period rather than assuming every date filter means the same thing.
Odoo’s Pipeline Analysis defaults to opportunities created during the current year. Odoo’s default Pipeline Analysis measure is the number of opportunities. These Odoo defaults are worth inspecting before interpreting a newly opened report. A useful-looking initial graph may answer a different question from the one your team intended.
Odoo’s Count measure totals opportunities matching the search criteria. Preserve those criteria in the metric card. If a viewer changes the filters, the explanation should change with them or make the active settings easy to inspect. A number copied into a presentation without its filter context is difficult to defend or reproduce.
How can filters change the apparent result?
Odoo automatically archives lost opportunities, but not every archived opportunity is lost. That distinction matters for a completed-opportunity review. Do not use “archived” as an unexplained synonym for “lost”. Select the documented status criteria that match your question and retain the included record list as evidence.
Odoo warns that a win/loss report can omit lost opportunities if archived records are not included appropriately. Test the exception with a fictional lost record that is archived. Check whether it appears in the intended report and inspect the filter configuration if it does not. A chart that renders successfully can still omit a material part of the population.
Use a small fixture register to make the expected count inspectable. Give each record a fictional identifier, state and relevant dates. Calculate the expected membership by hand. Then compare the report’s underlying records, not only its total, because two different mistakes can occasionally produce the same number.
| Metric-card field | Example definition to resolve | Why it matters |
|---|---|---|
| Question | Which completed opportunities were won or lost? | Establishes the decision |
| Population | Defined opportunity types and states | Prevents mixing unlike records |
| Time basis | Agreed date field and period | Makes period membership explicit |
| Exclusions | Tests, duplicates or other agreed categories | Makes omissions reviewable |
| Viewer scope | Personal, team or authorised wider view | Explains legitimate differences |
| Action | Named owner reviews identified exceptions | Turns the view into work |
Who can see the dashboard and its records?
Microsoft requires Power BI visualisations to be enabled before adding them to personal model-driven-app dashboards. The user needs a Power BI account and access to a Power BI dashboard. These are prerequisites in Microsoft’s embedding instructions. Treat them as conditions of that documented workflow, not a reason to assume that any CRM user automatically has access to the embedded service.
Microsoft says this embedding workflow requires third-party cookies for Power BI authentication. Ask the system owner to assess the documented requirement against the organisation’s browser policy and intended user environment. Record the chosen approach and demonstrate it. Do not advise users to weaken an existing browser policy casually just to make a demonstration work.
Sharing this personal dashboard requires configuring sharing in both Dataverse and Power BI. Microsoft requires appropriate access in both services for the shared dashboard’s viewers. Test the shared view with the intended viewer account. The dashboard creator’s success does not prove that a colleague has the same access. Equally, a blank visual may be an access or authentication issue rather than an absence of records.
Keep data scope visible during the review. An individual and a manager may legitimately see different populations, but the difference should follow the agreed permissions. Check the chart, the underlying records and any available export path relevant to the design; a dashboard permission decision should not stop at its opening screen.
Original CRM metric-definition and access card
Use a hypothetical register containing two won opportunities, one lost opportunity that is archived, one active opportunity and one test record. For the proposed completed-opportunity view, include won and lost business records and exclude the test. These are exercise rules, not a recommended universal reporting formula.
Membership pass: Write the identifiers expected in the view before opening the report. Record why the active and test records are excluded. Then inspect the report’s detailed list. Explain any difference at record level instead of changing the definition after seeing the chart.
Date pass: Give one completed record a creation date outside the reporting period and a closure date inside it. Compare a creation-based view with the agreed closure-based view. The exercise reveals whether the dashboard’s title accurately describes the date field being used.
Archive pass: Inspect the lost fixture after the intended filter is applied. Record the archived-record setting and actual membership. Keep that setting with the saved report definition so a later recreation does not silently omit lost work.
Viewer pass: Open the dashboard as an authorised salesperson and as an authorised manager in the test environment. Compare their expected scopes, visuals and record drill-throughs. Retain separate observations; do not assume that one role’s result represents everyone.
Action pass: Select an exception that requires follow-up and identify its owner. Write the action and the record where it will be tracked. If the dashboard cannot lead a viewer to the relevant record or responsible team, record that as a usability requirement rather than adding another summary chart.
What should be retained after the review?
Keep the metric definitions, fixture register, filter evidence and viewer observations together. Record the dashboard revision and the environment used. This creates a useful reference when a colleague later asks why their count differs or when a changed stage definition alters the view.
Review the card whenever the business changes its pipeline, permissions or reporting question. The dashboard should remain an explanation of the work, with a visible relationship between number, records and next action.
See business systems for broader CRM planning and web development for integration scope. To discuss an actionable dashboard, get started with the metric card and the specific decision your team needs to make from it.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.