Fast operational scan for status, load, overdue work and trends.
01 · Dashboards and reports
Operational reporting should stay close to the work it measures.
Turn operational data into metrics teams can review, explain, and open back to the underlying records—without exporting the work to a spreadsheet or separate BI tool.
Dashboards and reports use the same facts for different decisions.
A dashboard is for a quick scan of the operation. A report is for a larger, sectioned explanation. Both run from server-side data sources and keep drilldown connected to the underlying work.
Data source
Governed metric
A typed source returns bounded, permission-aware data for dashboards and reports.
Sectioned views for teams that need context behind the metric.
Links open records, board items or operational detail with access checked again.
Put KPIs, status lists, charts and record lists where operators can see load, backlog, overdue work or exceptions quickly.
Combine blocks into a structured report when a team needs context, sections and repeatable review rather than one widget.
Published reports appear through the runtime navigator after visibility and module requirements are checked.
Connect your own data sources when standard reports are not enough.
Start with trusted operational facts, define the metric once, and let users open the result back to the records behind it. Technical teams can add a typed C# source when a standard report is not enough.
Operational sourcesRecords, Moltaro Boards, and product modules provide the facts behind each metric.01
A clear metric definitionInputs, results, display, and drill-down behavior are defined before a report is published.02
Report blockSectioned views for teams that need context behind the metric.03
Records, Moltaro Boards, and product modules provide the facts behind each metric.
A technical team can keep customer-specific reporting logic as typed C# in a workspace-owned .NET project.
Inputs, results, display, and drill-down behavior are defined before a report is published.
Users can move from a number to the permitted records behind it without writing SQL or browser scripts.
A metric is only useful if the answer is allowed and explainable.
Runtime reporting checks visibility, module availability and data-source requirements before returning data. Drilldown reopens the underlying work through the same access model.
Dashboards and reports can be limited by users, roles, permissions and module dependencies.
Data is produced by backend sources with actor, locale, timezone and permission context supplied by Moltaro.
Opening a record, board item or operational detail checks access again instead of trusting the chart that linked to it.
Published definitions keep a source fingerprint, so incompatible source changes fail closed instead of showing misleading data.
Reporting definitions are configuration, not loose files.
Dashboards and reports are configured, previewed, published and archived as part of the runtime configuration story.
Build against a trusted sourceChoose source, bind filters, pick renderer, configure layout and preview the result.01
Validate before users rely on itPublished definitions are checked against source shape and access rules.02
Execute in runtime contextThe server runs sources with the current actor and returns bounded results.03
Retire without deleting historyOld definitions can leave the navigator while configuration history stays understandable.04
Reports matter because the number can lead back to governed work.
Boards, records, security and custom C# logic can all feed operational reporting, while the user still works inside the same Moltaro runtime.