How Pulse Dashboard works¶
Written from the Pulse Dashboard product and architecture notes kept with the source code, August 2026.
Most of what you need to use Pulse Dashboard is in the fundamentals guide. This page answers a different question, the one people ask once they have used it for a while: how is it doing that? Why does a filter you set on a tab reach reports that know nothing about each other. Why do totals stay right when you regroup. Why can your consultant add a field to your site and have it turn up on every report that could use it. And why is there no server to install.
The answers all come back to one idea, so it is worth stating first.
One idea, and everything follows from it¶
Pulse Dashboard stores almost none of your business data. What it stores are descriptions: which fields exist and where they come from in Macola®, how your reports are laid out, which filters are applied, and who is allowed to see what.
Every gesture you make — opening a report, adding a filter, grouping a column, clicking a number to drill in — is translated into a database question and sent to SQL Server, which is built for exactly that work. The server does the heavy lifting and sends back only the answer that fits on your screen.
Descriptions in the application. Data in the database. Questions written on demand.
Nothing on this page is a separate feature bolted on. Each one is that idea showing up somewhere different.
What lives where¶
The field catalogue is the list of every field Pulse Dashboard knows: what to call it, how to format it, whether it totals or averages, whether it is a key you can drill on, who is allowed to see it, and which Macola® table and column it actually comes from. Reports never name a Macola® column directly. They name a field, and the catalogue does the translating.
The report-ready tables are prepared copies of your Macola® data, built inside SQL Server. Joining raw Macola® tables on every refresh would be slow, so Pulse Dashboard assembles the data once into report-shaped tables and reads from those. They rebuild on demand and expire on a schedule your administrator sets, and they are careful about size: a table holds only the columns people are actually using. Ask for a new column and the next rebuild includes it from then on.
The translator is what runs when a report refreshes. It takes the state of the report in front of you — which columns are showing, how they are grouped and sorted, which filters are set — and writes one database question from it. Drill in and it writes the same question again with the values from the row you clicked added on.
Why one filter reaches reports that never met¶
A filter in Pulse Dashboard is not a piece of code inside a report. It is three pieces of information: a field, a test and a value. Because every report speaks the same field catalogue, "Customer No is 10240" means the same thing everywhere, and it can be handed to any report that has a customer number on it.
Filters also stack, and they inherit down a chain:
Your own access rights → the tab → the report → the drill-down
Each level adds to the ones above it, and none of them has to be coordinated by hand. Set a filter on a tab and every report on that tab narrows, whatever shape each one is. Drill into a number and the detail window is filtered by its own criteria, by its report's, by its tab's and by your access rights, all at once. A salesperson who only sees their own accounts gets that restriction applied at the top of the chain, so every question they ask is already limited to their own book of business.
The same mechanism is behind one of the habits worth picking up early. Right-click a customer, an item or an order number and Pulse Dashboard offers to carry that value somewhere else — into another report, or into a whole shared tab — arriving already filtered to it. Select several rows first and it carries the whole selection. No report has to be built as a destination, because a filter is something any report can accept, which is why the list of places you can jump to is as long as it is. Everyday tips covers the right-click menus more generally.
It is also why the Advanced Report Designer can pair any two reports and drive the second from the first. Neither report knows about the other. They agree on what a customer number is, and that is enough.
Why totals stay right when you regroup¶
Drag a column to group by it and the totals recompute. That is not the application re-adding numbers it already had on screen — the grouping change gets written into the question, and SQL Server totals the underlying records again at the new shape.
That matters most for the measures where naive arithmetic gets it wrong, and margin % is the one to know about. A percentage cannot be totaled the way a dollar amount can. Average the margin % of individual order lines and a $10 line counts as much as a $100,000 line, which gives you a number that looks reasonable and is not true. The right margin % for a customer, a month or the grand total is the ratio of the sums: total margin dollars divided by total sales dollars.
Pulse Dashboard does that for you, at every level, every time you regroup. The components are totaled first at whatever grouping you have chosen, and the percentage is worked out from those totals. You do not have to check which grouping a percentage is safe at, because there isn't one where it goes wrong.
For exactly how each figure on screen is worked out, see How Pulse Dashboard calculates its numbers.
Why a formula you invent behaves like a real column¶
A custom formula column is stored as the expression you typed, not as a column of computed values. When the report next refreshes, that expression is written into the question along with everything else, and SQL Server works it out while it is already reading the records.
Two consequences you will notice. Your formula filters, groups and totals like a column that shipped with the product, because by the time the data comes back it is one. And an unused formula costs nothing — no memory, no slower refresh — so you can build several while you work out what you want and delete the ones that missed, without tidying up afterwards.
Why your own fields turn up everywhere¶
The field catalogue is data rather than code, which is what lets it grow at your site. Your consultant authors new fields in a workbook — the caption, the format, how it totals, and which table and column it comes from in your database — and imports it. Those fields then appear in the Column Chooser of every report they apply to, and they filter, group, total and drill exactly like the ones that came in the box. Nothing is recompiled and no update is required.
The catalogue reserves space for them, so a Pulse Dashboard update adds its own new fields without ever colliding with yours, and an installer never touches your site's file. Your customizations survive upgrades by design, not by luck.
Why a customized Macola® database still works¶
Two more things fall out of reports naming fields instead of tables.
Customized schemas. Every table name Pulse Dashboard generates passes through a substitution layer first, so a site whose Macola® tables have been extended or replaced can have those substitutions configured once and everything downstream picks them up. That is configuration, not a code change.
One product, two Macola® generations. Macola® Progression and Macola® ES store the same information in materially different tables. Because a report asks for "Customer No" rather than for a physical column, the catalogue resolves it to the right place for the database you are on. One report body serves both.
Why your own SQL still obeys the dashboard¶
The Query Analyzer lets you put hand-written SQL on a tab. Turn on advanced dashboard integration and that query stops being a one-off: Pulse Dashboard wraps it and adds the active filter chain to it, so your SQL narrows with the tab like every other report. Where the columns your query returns match names in the field catalogue, they pick up their proper captions, formats and key behavior too.
So a script somebody wrote to answer one question becomes a report that participates in the dashboard, rather than a dead end that ignores whatever filter is set.
Where the work happens, and what you have to install¶
Pulse Dashboard is a Windows desktop application that talks to SQL Server, and there is nothing in between. There is no server component to install. Installing Pulse Dashboard means installing the client and pointing it at your database.
That is a direct result of the design on this page. Because the questions are answered by SQL Server rather than in the application, the heavy work runs on the database server — the one properly specified machine your IT department already looks after and already backs up. A workstation receives a few hundred rows and draws them. So a report over years of order history does not need a powerful PC, performance does not vary desk to desk, and adding users does not mean sizing new hardware.
What this means in practice¶
| What you do | What is happening | What it means for you |
|---|---|---|
| Set a filter on a tab | The filter joins a chain that every report on the tab inherits | One filter, every report, including ones added later |
| Drag a column to group by it | The grouping is rewritten into the question and the server re-totals | Totals stay correct at any grouping, margin % included |
| Click a number to drill in | The same question runs again with the clicked row's values added | The detail always matches the number you clicked |
| Build a formula column | The expression is written into the next question | It filters, groups and totals like a shipped field, and costs nothing when unused |
| Have a field added at your site | A row is added to the field catalogue | It appears across every report that can use it, and survives updates |
| Right-click a value and jump | The value is carried as a filter into the destination | Every report is a valid destination, without being built as one |
| Refresh a report | The prepared table is read, or rebuilt first if it has expired | Refresh time depends on your server, not on your PC |
Where to go next¶
- Pulse Dashboard fundamentals — the working guide: refreshing, columns, sorting, filtering and sharing a tab
- Advanced techniques — formula columns, the Advanced Report Designer, the Query Analyzer and publishing
- How Pulse Dashboard calculates its numbers — the definition behind each figure on screen
- Reporting modules — what ships on each module's tabs
- Administration — users, security, company settings and the report Scheduler
Support & contact¶
Our team is glad to go through any of this with you, including how it would apply to your own database.
- PULSE software support — (513) 723-8095 · [email protected]
- Sales & product questions — (513) 723-8091 · [email protected]
- Consulting & Macola® services — (513) 723-8094 · [email protected]