Building useful Kinetic dashboards on BAQs

Dashboards are where most people in a Kinetic shop meet their data. Built well, a dashboard answers a question someone asks every day in a few seconds. Built badly, it is a slow grid of 60 columns that nobody trusts, and the answer people use lives in a spreadsheet next to it. Below is how we design Kinetic dashboards so they end up in the first group.

It stays at the level of design decisions. Screen layouts and designer steps change between releases, so where exact behavior matters we say so and you should confirm it in your version.

What a Kinetic dashboard is made of

Epicor describes Business Activity Queries (BAQs) as reusable query definitions that feed reports, dashboards, APIs and analytics without direct database access, and presents grids, charts and dashboards as different ways to view a query result. A dashboard has three layers:

Layer	What it does	Where mistakes show up
BAQ	Selects, joins, filters and calculates the data	Wrong totals, slow loads, too many rows
Dashboard views	Grids, charts, trackers and summaries that present BAQ results	Cluttered screens, columns nobody reads
Links between views	Selecting a row in one view filters another	Detail grids that show the wrong rows, or nothing

In the Kinetic browser interface, dashboards are built and tailored with Application Studio, which Epicor positions as its low-code tool for screens and dashboards. Older dashboards built in the Windows client designer may need converting or rebuilding. Confirm the path for your version before planning a large dashboard project.

Start from the question, not the table

The most common reason a dashboard goes unused is that it was designed from the data outward: "show everything about open orders." Start from the decision instead.

1. Write the question in one sentence. "Which open orders promised this week are at risk because stock is short?" is a dashboard. "Order information" is not.
2. Name the person and the moment. Who opens this, and when? The customer service lead at 8 a.m. needs a different screen from the operations manager's weekly review.
3. List the columns that answer the question. For each one, ask what the user will do differently because it is there. If the answer is nothing, leave it out.
4. Decide the grain. One row per order, per order line, or per release? Everything else follows from this, including whether totals are right. See BAQ fundamentals for why grain decides correctness.
5. Decide what "done" looks like. A row should leave the dashboard when the user has dealt with it. A dashboard that only grows becomes a report nobody reads.

One BAQ per grid

It is tempting to build one large BAQ and point every grid on the dashboard at it. We prefer one focused BAQ per grid:

• Each query stays at one grain. A header grid and a line grid built from one query force one of them to repeat or aggregate rows, and totals drift.
• Each query returns only what its grid shows. Smaller result sets load faster and are easier to test.
• Changes stay contained. Adding a column for the detail grid does not change the rows in the summary grid.
• Queries become reusable. A well-named "open order lines at risk" BAQ can feed a dashboard, a report and an API call. Epicor presents BAQs as reusable across those uses.

Link the grids with keys (company, order number, customer, part) rather than duplicating data across them.

Parameters versus dashboard filters

There are two broad ways to narrow what a dashboard shows, and the table compares how they behave.

	BAQ parameters and query criteria	Filters on the dashboard view
Where it runs	In the query, on the server	Against rows the query already returned
Effect on speed	Fewer rows read and sent	None on the query, because all rows still load
Good for	Required scoping: date range, site, sales rep, "only my customers"	Quick slicing of a small result set by the user
Risk	A required parameter the user does not understand	A filter that hides rows the user forgot about

As a rule of thumb, anything that cuts the data by more than half belongs in the query, as fixed criteria or a parameter. Screen filters are for convenience on data that is already small. How parameters are prompted, defaulted and passed from one view to another varies by version and by how the dashboard is built, so confirm in your version.

A filter is not security

Hiding rows with a dashboard filter does not stop a user from seeing them. If some people must not see certain data, restrict it in the BAQ and its security.

Published BAQs and security

A dashboard is only as safe as the BAQs underneath it. Three separate things decide who sees what, and all three need a decision:

• Who can run the BAQ. BAQs can be private to their author or shared, and access can be restricted by security settings. A dashboard built on a private or restricted BAQ may show nothing to other users.
• Who can open the dashboard. Deploying a dashboard to a menu brings it under menu security. Someone with access to the menu item but not to the BAQ gets an empty or failing screen.
• Which company and site data the query can see. Multi-company and multi-site installations need a deliberate choice about scope. Confirm in your version how BAQ company visibility and user site access interact.

A few habits help:

• Never build production dashboards on a personal, unpublished BAQ. When that person leaves, the dashboard breaks.
• Treat updatable BAQs as data entry. A dashboard that writes back to the database needs the same validation as any other entry point. Put rules that must always hold in a BPM, as we explain in Epicor Functions, BPMs or customizations?.
• Review sensitive columns. Cost, margin, pay rates and customer contact details should appear only on dashboards whose audience is cleared to see them.

Performance habits

Most slow dashboards are slow because of the query, not the screen. These habits matter most:

Habit	Why
Return only the columns the grid shows	Every extra column is read, sent and rendered for every row
Filter as early as possible	Criteria on the table or inner subquery cut rows before joins multiply them
Pre-aggregate in a subquery	Summarize at the grain you need before joining descriptions, instead of returning detail and summing on screen
Avoid calculated fields over large sets	A formula over hundreds of thousands of rows, especially one that cannot use an index, is often the slowest part
Be careful with outer joins	They are sometimes needed, but each one widens the work and can hide rows from totals
Limit automatic refresh	A dashboard that refreshes every minute on 30 desks is 30 queries a minute, all day
Keep history out of live views	Last year of shipped orders belongs in a separate, parameterized query or an analytics tool

If a dashboard needs heavy analysis across years of data, it may be the wrong tool. Epicor offers separate analytics products for that kind of work, and a BAQ can feed them without the dashboard carrying the load.

Drill-down and linked grids

Linked views are what make a dashboard more than a report. Select a customer in one grid and the order grid shows only the orders for that customer. Conceptually this is a publish and subscribe relationship. One view publishes a value from the selected row, and another view subscribes to it and filters on it.

Design the links on paper before building them:

• Publish keys. Filter on customer number rather than customer name, because names repeat and change.
• Make the direction obvious. Summary on the left or top, detail to the right or below. Users should never wonder which grid drives which.
• Decide whether the detail view filters rows already loaded or runs its own query with the selected key as a parameter. The second scales better when the detail data is large. Which options are available depends on your version and how the dashboard is built, so confirm in your version.
• Show an empty state on purpose. A detail grid with nothing selected should look deliberately empty, not broken.
• Keep chains short. Three levels (summary, record, detail) are enough for most dashboards. Deep chains are hard to test and hard to explain.

Test totals against a report you trust

A dashboard total that disagrees with the finance report destroys trust in both. Before a dashboard goes live, test it the way you would test a new report.

1. Pick a trusted source. Use a standard report the business already relies on, or a figure finance has reconciled, for the same period and filters.
2. Compare totals and counts. Check sums of quantity and value, row counts and the number of distinct orders or customers.
3. Explain every difference. Common causes are a join that repeats a header value on every line, a status filter that differs, an outer join that drops rows with no match and mixed currencies. BAQ fundamentals walks through each.
4. Test at least one edge case by hand, such as a cancelled line, a partial shipment, a credit memo or a multi-currency customer.
5. Record the check. Note what you compared, when and the result, in the BAQ description or your documentation. Repeat it after upgrades.

Naming, ownership and retirement

Dashboards multiply. Within a few years most companies have more than anyone can list, and many are built on BAQs that no longer mean what their names say. A little governance prevents that.

Practice	What we recommend
Naming	A consistent prefix for your company's BAQs and dashboards, then area and purpose: for example ACME-SO-OpenLinesAtRisk. The name should say what the query returns
Description	Every BAQ and dashboard carries a sentence on its purpose, its grain, its owner and its trusted comparison
Ownership	One named business owner per dashboard, who decides changes and confirms it is still needed
Change control	Build and test in a non-production environment, then move to production through export and import or your normal deployment process
Inventory	A simple list of dashboards, their BAQs, owners and last review date. At upgrade time, it is your test list
Retirement	Review usage at least yearly. Retire dashboards with no owner or no recent use, and keep an export before deleting

Retiring a dashboard is healthy. Each one you remove is one fewer thing to test at upgrade and one fewer place a wrong number can hide.

Before you build

Write the question, the user, the grain and the trusted comparison on one page before opening any designer. If you cannot fill in all four, the dashboard is not ready to build. When you can, start with the smallest BAQ that answers the question, prove its totals and add views only when someone asks for them.