Fast operational scan for status, load, overdue work and trends.
01 · Dashboards and reports
Operational reporting should stay close to the work it measures.
Moltaro dashboards and reports turn governed runtime data into metrics teams can scan, explain and open, without exporting the operation into a separate spreadsheet or BI island.
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.
The important extension point is the C# data source.
A data source describes parameters, output shape, compatible renderers, execution policy and drilldown. Moltaro executes it on the server and renders the result in dashboards or reports.
Moltaro modules can provide sources for their own operational facts, such as board state and platform metrics.
Customer-specific reporting logic belongs in NetOperationProject, where a team can keep typed C# in a workspace-owned .NET project.
Parameters, output schema, renderers and drilldown are described before execution, so published definitions can be validated.
Users configure reports from trusted sources. Arbitrary SQL and ad-hoc browser scripts are not the reporting model.
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.