What Tables and APIs Should an Enterprise Prepare Before Starting a Data Dashboard Project?

Summary: Before starting a data dashboard project, prepare a metric list, sample data tables, API descriptions, access rules, screen dimensions and acceptance goals. Clearer materials make design, development and integration easier to advance.

Start with a Metric List

The list does not have to cover every business area at first. It should define each key metric’s name, calculation, time range, filters and owner. For example, is sales measured by orders, payments received or invoices? Is equipment online rate based on live status or the most recent report?

Divide metrics into essential, recommended and later-iteration items. The first dashboard should make the core figures accurate, explainable and reliably refreshed before adding more charts and linked effects.

Organize Sample Data Tables

An enterprise can begin with Excel or CSV files, database table structures or exports from existing systems. Samples should preserve real field names and representative relationships. Sensitive values may be masked, but do not arbitrarily change how fields relate.

If several departments provide data, identify the owner and refresh frequency for each field. This helps determine during design which metrics can be shown live and which should update daily, weekly or monthly.

Confirm APIs and Source Systems

Dashboards often connect ERP, MES, CRM, WMS, IoT platforms, energy systems or internal databases. Before kickoff, confirm whether each API is available, who provides it, how often it updates, whether authentication is needed and whether there is a test environment.

If APIs are not ready, authorized sample data can still be used to approve the prototype, visuals and page structure. Field mapping and live integration can follow.

Do Not Forget Permissions and the Display Environment

If the dashboard contains business, customer, financial or production data, define which roles may see it. Screen size, installation site, browser and internal or external network access also affect responsive design and deployment.

Common settings include meeting rooms, showrooms, command centers, duty rooms and mobile viewing. They need different text sizes, information density, refresh behavior and operating permissions.

Common Kickoff Mistakes

One mistake is bringing only reference images, with no real metrics or sample data: design moves quickly but integration is repeatedly revised. Another is failing to assign an API owner until development is well under way. A third is approving the visuals without agreeing on acceptance rules, leaving the parties with different meanings of “finished.”

A more reliable sequence has three layers: confirm the presentation goal and page scope, then metrics and sources, and finally APIs, permissions, deployment and acceptance. Even if some APIs are pending, the overall project decision can continue.

Preparation itemWhat to includePurpose
Metric listName, definition, unit and time rangeDefine screens and calculation logic
Sample dataExcel files, database fields and system exportsSupport prototypes and API design
API descriptionEndpoint, fields, authentication and refresh rateSupport development and integration testing
Permission scopeRoles, menus and visible data rangesPrevent unnecessary exposure of sensitive data

Define Acceptance Goals Early

Acceptance is about more than how the page looks. Check metric definitions, data refresh, permission accounts, deployment environment, browser compatibility, error messages and handover documents. Beijing Hongshan Technology recommends writing the acceptance checklist at kickoff to avoid last-minute scope additions.

A Useful Order for the First Discussion

  1. Start with the business goal: who will view the screen, what problem should it solve and where will it be used?
  2. Then describe the page structure: which overview, detail, specialist and administration pages are needed?
  3. Next identify sources: which values come from spreadsheets, which from systems and which need live APIs?
  4. Finally define launch conditions: where will it run, who manages access, how will it be accepted and who maintains it?

This order helps a provider distinguish what can start now from work that must wait for APIs or permissions.

Related Pages

Related services: Data visualization dashboard development, BI dashboard development. Related guidance: How to Build a Data Visualization Dashboard, How Enterprise Dashboard Data Is Integrated.

Further Reading

Preparation should also cover provider capabilities, quotation scope and acceptance boundaries.

How to Select a Data Visualization Dashboard Development Provider

Check whether the team understands the business scenario, sources and handover boundaries.

View provider selection guidance

How Much Does a Data Visualization Dashboard Cost?

Consider how pages, APIs, administration and deployment affect the budget.

View dashboard cost factors

Data Dashboard Project Acceptance Criteria

Agree on page, data, permissions, performance and handover checks before launch.

View the acceptance checklist