Why Build a Custom Executive Dashboard When You Already Have BI?
Summary: Having BI does not automatically mean an organization needs another executive dashboard. Existing BI can continue to support general analysis. When non-public operating information, detailed cost and profit data, key customer contracts, or other sensitive information should not enter a shared BI environment, a custom dashboard can be deployed separately on a controlled network according to the data boundary, with dedicated APIs, identity permissions, export restrictions, and audit logs.
Short answer: One important reason to add a custom dashboard alongside BI is to separate general analysis from sensitive management data. Separate deployment is only one technical measure. Data sources, network, accounts, APIs, fields, exports, logs, backups, and operations access must also be controlled. If legally designated state secrets are involved, the project must follow the formal construction and review process for classified information systems.
First ask whether the existing BI is already sufficient
“Executives rarely use BI” does not, by itself, mean “we need a custom dashboard.” The problem may be permissions, poorly organized fixed reports, a buried entry point, inconsistent metrics, unreliable refreshes, or missing training. If these can be fixed in the current BI, improving it directly costs less.
Test real management tasks first: Can a manager find core metrics within the required time, see why an exception occurred, open permitted details, and take the next relevant action? If configuration of the existing system can meet those needs, avoid building the same thing twice.
Which gaps may justify a custom executive dashboard?
| Actual gap | Improve existing BI only | Consider a custom dashboard |
|---|---|---|
| Fixed management view | The product supports home pages, favorites, subscriptions, or pinned reports. | Information across modules must be organized for a role, meeting, or staffed operations task. |
| Cross-system metrics | The current data model can connect sources reliably and unify definitions. | Multiple business APIs, live equipment, files, and metric versions need to be integrated. |
| Identity and permissions | Built-in organization roles, row and column permissions, and single sign-on are sufficient. | The page must inherit centralized identity, organizational hierarchy, field masking, and rules for dedicated devices. |
| Interface and interaction | The product's components and filters complete the user task. | Dedicated layouts, maps or 3D scenes, linked operations, or different experiences across devices are needed. |
| Business actions | Users only need to view, filter, drill down, and export. | An exception should lead into a work order, approval, customer, project, or equipment response process. |
| Data sensitivity | The shared environment's users, export and sharing controls, and operations privileges meet requirements. | Sensitive or restricted data cannot enter general BI; data sources, network zones, accounts, fields, exports, and logs must be limited. |
| Deployment and operations | The existing topology, licensing, upgrades, and monitoring meet requirements. | The solution must fit an isolated network, specific hardware or software, centralized logs, or a dedicated release process. |
A typical case: Keep sensitive data out of general BI
A company's general BI may serve many sales, operations, project, and finance roles and be well suited to authorized day-to-day analysis. Board materials, non-public business plans, detailed costs and margins, key customer contracts, restricted R&D or production information, or highly sensitive personal data may not belong in the same shared dataset, account system, and export path.
In that case, retain the current BI and deploy a custom executive dashboard separately in an approved network zone. Connect only approved data sources and metrics. Apply separate or stricter identity permissions, restrict exports, copying, sharing, and external access, and log queries, exports, configuration, and permission changes. This is not two duplicate reporting systems; it is a division by data sensitivity and audience.
| Isolation dimension | Recommendation for the custom dashboard | Acceptance evidence |
|---|---|---|
| Data sources | Connect only approved databases, views, or read-only APIs; do not copy all sensitive details into general BI. | Data-source inventory, field mapping, account permissions, and recalculated samples. |
| Network and deployment | Choose dedicated resources, a controlled network zone, or an isolated environment according to policy, and define cross-zone transfer paths. | Network topology, port inventory, access tests, and exchange approvals. |
| Identity and permissions | Grant access by role, organization, and data level; add multifactor authentication or dedicated-device restrictions where needed. | Permission matrix, positive and negative account tests, and account deprovisioning records. |
| Display and export | Mask sensitive fields; disable or require approval for exports, copying, printing, and sharing by role. | Field masking results, export controls, direct API tests, and historical-link tests. |
| Logs and operations | Log sign-ins, queries, exports, configuration, and permission changes; restrict operations accounts and protect backup media. | Audit logs, alerts, operations authorization, restore tests, and key-rotation records. |
Whether physical isolation, a separate database, or fully separate accounts are required depends on data classification, industry requirements, network conditions, and risk assessment. “This data is important” alone is not enough to determine an architecture mechanically.
Do not confuse “sensitive enterprise data” with “state secrets”
Business data labeled “confidential,” “secret,” or “sensitive” inside a company is not necessarily a state secret in the legal sense. For ordinary sensitive, important, or personal information, isolation, masking, minimum permissions, and audits can be determined under company policies, industry rules, and data-classification results. China's Data Security Law establishes a classified and graded data-protection system; the protection level should reflect the data's importance and the potential harm from disclosure, tampering, or illegal use.
If a competent authority or organization has legally designated the data as a state secret, the project is no longer ordinary “private deployment.” China's Regulations for the Implementation of the Law on Guarding State Secrets require a classified information system's protection level to follow the highest classification of information it handles, with testing, evaluation, and review before use as required. Organizations carrying out classified-system integration or other classified business must also meet the relevant qualification requirements. Ordinary custom development therefore cannot market “a separate server” as a classified-system compliance solution.
Which capabilities should a custom dashboard avoid rebuilding?
First assess whether to reuse capabilities that already operate reliably in BI or the data platform:
- Business-approved data warehouses, datasets, metric definitions, and historical versions.
- Central identity, organizational structure, account lifecycle, and data-permission rules.
- Self-service analysis, detailed queries, advanced filtering, subscriptions, and standard exports.
- Data-quality monitoring, task scheduling, metadata, lineage, and operations alerts.
A custom dashboard is better used to add a management entry point, cross-system integration, dedicated interactions, and links into business workflows. Rebuilding ingestion, permissions, and metric calculations raises cost and makes conflicting figures across two pages more likely.
How to divide work in a hybrid architecture
- Data layer: Retain the current data warehouse, datasets, or metric service and establish one authoritative source for each definition.
- Analysis layer: Continue using BI for exploratory analysis, filtering, drill-down, details, and ad hoc reports.
- Dashboard layer: Show goals, key metrics, trends, risks, and task entry points in fixed views tailored to each role.
- Business systems layer: Work-order, approval, customer, project, or equipment systems remain responsible for official business actions.
- Identity and permissions layer: Map centralized sign-on and organizational roles; avoid maintaining separate accounts in BI and the dashboard.
When navigating from the dashboard to BI or a business system, carry useful context such as time period, organization, and project where possible, then recheck permissions in the destination. A link between pages is not permission to bypass authorization.
Confirm API and licensing boundaries before implementation
Whether BI can be reused should not be decided by a developer trying calls until one works. Confirm together:
- Whether supported APIs, embedding, datasets, or semantic-layer access are available.
- Whether embedded users, concurrency, external access, exports, and single sign-on require additional licenses.
- API versions, rate limits, caching, upgrade compatibility, and vendor support responsibilities.
- Whether data permissions remain effective at the API layer or must be rechecked at a gateway or metric service.
- How the dashboard will degrade gracefully or migrate if a third-party component is retired, upgraded, or replaced.
Avoid scraping BI pages, calling unpublished APIs, or sharing highly privileged accounts to keep an integration running. Such approaches are hard to audit and may fail after an upgrade.
How to keep metrics consistent across two systems
For every core metric, record its business definition, formula, source, version, effective date, owner, approval state, lineage, dashboards that use it, and permission level. BI and the dashboard should point to the same dataset, semantic layer, or metric service. If performance requires caching, document refresh frequency and delay.
Before launch, recalculate samples for the same organization, reporting period, and source data in both systems. Include normal, null, reversal, cross-period, and differing-permission scenarios. The metric-definition and data-lineage acceptance matrix (Chinese) can retain the results.
An actionable project decision
- Keep improving existing BI: The main gaps concern its home page, permissions, report organization, training, or data quality.
- Build a limited integration: A shared portal, embedded fixed reports, single sign-on, or a few management entry points are needed.
- Build a custom dashboard: Cross-system metrics, complex permissions, dedicated interactions, business actions, and deployment requirements exist together.
- Delay the project: Metric owners, data sources, management tasks, or acceptance criteria remain unclear.
If you decide to implement, next compare BI extension, embedded integration, and independent custom development and agree in advance on deliverables and responsibility boundaries.
Frequently asked questions
Is adding an executive dashboard when we already have BI duplicate development?
If both systems model the same data and calculate the same metrics separately, differing only in appearance, duplication risk is high. A dashboard that reuses the current BI or data platform's metrics and focuses on fixed management views, cross-system summaries, dedicated interactions, and business actions has a distinct role.
Can an executive dashboard read data directly from BI?
It depends on whether the existing BI supports APIs, embedding, datasets, or semantic-layer access and what licensing and permission boundaries apply. If stable supported access is unavailable, integrate with a governed data warehouse, metric service, or business API; do not depend on scraping pages.
Is managers' difficulty using BI sufficient reason to build a dashboard?
No. First see whether permissions, pinned reports, favorites, training, or home-page changes can solve the issue. A custom entry point makes more sense only when the actual tasks, cross-system information, interaction flow, or deployment boundaries consistently exceed product capabilities.
How can BI and a custom dashboard keep metrics consistent?
Assign one owner to each metric, align names, formulas, scope, versions, effective dates, and lineage, and make both interfaces reuse the same dataset, semantic layer, or metric service. Recalculate against the same sample and period before release.
Why not put sensitive data into our existing BI?
If the current BI serves a broad audience, runs in a shared network, or permits export and sharing, adding highly sensitive data may widen access. Depending on data classification and company policy, keep it in a controlled source or isolated network and let the custom dashboard access it through allowlisted APIs, dedicated identity permissions, field masking, export controls, and audit logs.
Does deploying a custom dashboard separately satisfy classified-system requirements?
No. Isolating ordinary enterprise-sensitive data and handling legally designated state secrets are different matters. If a system legally stores or processes state secrets, it must be planned, built, assessed and reviewed, operated, and maintained under applicable state secrecy rules and standards, with qualified organizations performing relevant classified work. Ordinary private or separate deployment is not a substitute.
Sources and applicability boundaries
- Data Security Law of the People's Republic of China | Office of the Central Cyberspace Affairs Commission: Data classification and graded protection framework.
- Regulations for the Implementation of the Law of the People's Republic of China on Guarding State Secrets | National Administration of State Secrets Protection: Classified-system protection levels, testing and review, and qualifications for classified business.
These sources explain the legal distinction between data classification and state secrets. They are not an external legal review, compliance certification, or claim of classified-project qualification. For a specific project, the client's data, security, and legal teams and relevant authorities should confirm the rules against the actual data and policies.