Cross-Plugin Dashboard
Cross-Plugin Dashboard pulls data from your deployed plugins into one executive view with summary cards, record counts, and plugin-specific highlights. Use it when leaders need a quick read across tools without opening each app one by one.
Trusted by frontline teams 15 years of frontline software
Built for: Saas Operations · Professional Services · Multi Site Retail · Light Manufacturing
Overview
Cross-Plugin Dashboard is an analytics template for aggregating data from other deployed plugins into one read-only executive view. It is built for situations where teams already use several small operational apps and need a single place to see record counts, key totals, and a few source-specific highlights without jumping between tools.
The template is a good fit when leaders want a quick status layer across plugins such as expense-tracker, team-kudos, inventory, maintenance, or booking apps. It is especially useful when each source plugin has its own record type and workflow, but the business only needs a compact summary at the top level. The dashboard should show one card per detected plugin, plus any special metric that makes sense for that source, such as total spend or top recognized employees.
Use this template when you need visibility, not transaction handling. Do not use it as the primary place to create, edit, approve, or resolve records, and do not expect it to replace the source plugin's detail screens. If a plugin is missing, disabled, or returns no data, the dashboard should still load and show a graceful empty state. The best implementations keep the card set small, label each metric clearly, and make it obvious which source plugin produced each number.
How to use this template
- 1. Connect the dashboard to the plugins you want to summarize and define which record types or metrics each source should expose.
- 2. Configure the summary cards so each detected plugin shows a clear label, a record count, and any plugin-specific metric such as spend, open items, or recognition totals.
- 3. Set role permissions so executives and managers can view the dashboard while source-plugin editors keep their normal create and update access in the underlying apps.
- 4. Run the dashboard on a schedule or on load, then verify that missing plugins, empty datasets, and tool errors fall back to a readable empty state instead of breaking the page.
- 5. Review the output against the source plugins, confirm the totals match, and refine the card layout so the most important metrics appear first.
Best practices
- Keep each card tied to one source plugin and one primary metric so the dashboard stays scannable.
- Label every number with its source plugin and record type so users do not confuse aggregated counts with source-system totals.
- Gracefully hide or gray out missing plugins instead of surfacing errors that make the whole dashboard look broken.
- Use read-only permissions for the dashboard itself and leave record edits in the source plugins where the workflow belongs.
- Validate totals against the source records before rollout so the executive view does not drift from the underlying data.
- Prefer a small, high-signal card set over a long wall of metrics that requires interpretation.
- If a plugin has no meaningful aggregate, show record count or status breakdown rather than inventing a weak metric.
What this template typically catches
Issues teams running this template most often surface in practice:
Common use cases
Frequently asked questions
What does the Cross-Plugin Dashboard template actually include?
It includes a dashboard that detects deployed plugins, calls their available tools through plugin interop, and renders summary cards for each source. The template is designed to show record counts by plugin and can surface plugin-specific metrics such as total spend from expense-tracker or top recognized employees from team-kudos. It also defines how to handle missing plugins so the dashboard still loads cleanly. This makes it a starting point for a unified read-only analytics view rather than a full reporting suite.
Which plugins can this template work with?
It works with any deployed plugin that exposes data the dashboard can read through plugin interop. The embedded prompt specifically calls out expense-tracker and team-kudos as examples, but the pattern is broader: any plugin with accessible records can be summarized as a card. If a plugin is not deployed, the dashboard should skip it gracefully instead of failing. That makes the template suitable for mixed environments where plugin availability changes over time.
How often should the dashboard refresh?
Use it for near-real-time or scheduled refreshes depending on how often the source plugins change. For operational dashboards, a short refresh interval is useful when managers need current counts or spend totals. For executive reporting, a daily or hourly refresh is often enough and reduces unnecessary calls to source plugins. The right cadence depends on how fresh the underlying records need to be when decisions are made.
Who should own and maintain this dashboard?
A product owner, operations lead, or analytics admin usually owns it because the dashboard spans multiple data sources. They decide which plugins are included, which summary cards matter, and how missing data should be presented. Source-plugin owners should be consulted when a metric needs interpretation, such as what counts as spend or recognition. This keeps the dashboard aligned with the meaning of each record type instead of just the raw totals.
What are the common mistakes when building a cross-plugin dashboard?
A common mistake is assuming every plugin exposes the same fields or record structure, which leads to brittle summaries. Another is failing to define fallback behavior when a plugin is missing, disabled, or returns no records. Teams also often overload the dashboard with too many cards, which makes it harder to scan. The template helps by focusing on a small set of summary cards and explicit handling for absent plugins.
Can I customize the metrics shown on each card?
Yes. The template is meant to be cloned and adapted so each plugin card can show the metric that matters most for that source. For one plugin that may be record count, while another may be total spend, top performers, open items, or status breakdowns. You can also rename cards to match internal terminology. The key is to keep each card tied to a clear record type and a single purpose.
Does this replace the source plugins' own dashboards?
No. It is an aggregation layer, not a replacement for the detailed screens inside each source plugin. The dashboard is best for executive scanning, cross-tool comparison, and quick status checks. Users should still open the source plugin when they need record-level detail, edits, or workflow actions. That separation keeps the dashboard lightweight and avoids duplicating each plugin's full functionality.
How do I roll this out without confusing users?
Start with a small set of source plugins and a narrow list of metrics that leadership already asks for. Label each card clearly so users know which plugin it came from and what the number represents. Then validate the dashboard against the source plugins to confirm counts and totals match expected values. A phased rollout also gives you time to decide which plugins should be visible to which roles.
Related templates
Ready to use this template?
Get started with MangoApps and use Cross-Plugin Dashboard with your team — pricing built for small business.
