Skip to content

Reporting

The workflow module exposes the request data through five views, plus the standalone audit-log screen for cross-request queries. This page walks each one and points at the four KPIs we recommend tracking weekly.

The five views over maintenance.request

Kanban (default landing view)

Maintenance → Maintenance opens the kanban grouped by stage.

The workflow module enhances the standard cards with three things (see view_maintenance_request_kanban_roots_hemms_workflow):

  • A criticality dot (green / yellow / red) — pulled related from the equipment's roots_criticality_color
  • A red SLA badge when the breach flag is True
  • The Current Responsible avatar + name at the bottom of the card

Columns are sorted by sequence so the flow reads left-to-right:

PM Scheduled │ Submitted │ Pending Review │ In Repair │ Awaiting Pickup │ Received
   (5)      │   (10)    │      (20)      │   (30)    │      (40)       │   (50)

The Received column is folded by default (fold=True) so completed work doesn't clutter the active board.

Quick triage routine

Every morning: open the kanban with the Critical Equipment filter on. The red-badge cards are your priority queue. Then flip off the filter and look at any red SLA badges — those are the next escalations.

List view

Switch via the view-mode toggle. Adds three workflow columns after the standard ones:

Column Source Notes
Responsible roots_current_responsible_user_id avatar widget
Time in Stage roots_time_in_current_stage_hours float_time
Criticality roots_equipment_criticality_color badge, optional show

The whole row turns red when roots_is_sla_breached is True (decoration-danger on the inherited list element). The breach column itself is hidden (column_invisible="1") but drives the row colour.

Calendar view

Inherited from base maintenance. The workflow module doesn't modify it — but the standard calendar plots requests by request_date and schedule_date, useful for forecasting PM workload by week.

Pivot / graph

Maintenance → Reporting → Maintenance Request Analysis — Odoo's stock report, re-homed under the canonical Reporting menu by views/maintenance_menus.xml.

Useful pivot configurations:

  • Rows: Stage. Columns: Month. Measure: Count. → How many tickets pass through each stage each month.
  • Rows: Equipment. Columns: Stage. Measure: Count. → Which equipment hits the workflow most often (recurring problems).
  • Rows: Current Responsible. Measure: SLA Breached (count). → Who's accumulating breaches.

The workflow fields (roots_current_responsible_user_id, roots_is_sla_breached, roots_equipment_criticality_color) are all available as pivot dimensions — they're stored where it matters and indexed where queries hit them.

Search filters and Group By presets

The search bar carries the workflow-specific filters (view_maintenance_request_search_roots_hemms_workflow):

Filter Domain
My Responsibility roots_current_responsible_user_id = uid
SLA Breached roots_is_sla_breached = True
Critical Equipment roots_equipment_criticality_color = 'red'

Group By presets:

  • Stage (the default kanban grouping)
  • Current Responsible — useful in list view to see each technician's queue
  • Equipment Criticality — green / yellow / red rollups

The Stage Transition Audit Log

Maintenance → Configuration → Stage Transition Audit Log — manager-only (gated by maintenance.group_equipment_manager).

The list shows every transition across every request:

Column What it means
Transitioned At Wall-clock timestamp of the stage change
Request M2O to maintenance.request (click to drill down)
From Stage Empty for the create-time entry
To Stage Destination stage
Transitioned By The res.users who triggered the write
Time in Prev Stage (h) Hours spent in the previous stage
Note Free-form, blank by default

Three Group-By presets are available:

  • Request — every transition for one ticket, in order
  • To Stage — all moves into a given stage; lets you sort the Time in Prev Stage column to find the slowest stages
  • Transitioned By — per-user workload + breach rate

Surveyor scenario: 'Show me PM compliance for Q1'

  1. Open the audit log
  2. Filter: From Stage = PM Scheduled (any move out of PM Scheduled is a PM acknowledgement)
  3. Date range: 1 Oct – 31 Dec
  4. Sort by Time in Prev Stage descending
  5. Anything over 72 hours is a PM-acknowledgement SLA breach; count them and divide by the total — that's the PM acknowledgement compliance %.

Four KPIs to monitor weekly

1. SLA breach rate

breaches_this_week / total_active_requests_this_week

UI: kanban with SLA Breached filter on, divided by the kanban without it. Anything above ~5% means SLAs are too tight or the team is under-resourced.

2. Mean Time To Repair (MTTR)

average(close_date - request_date) for requests closed this week

UI: pivot on Maintenance Request Analysis with the Stages filter set to Received and the date range to last 7 days; measure = average of (close_date - request_date). The standard Odoo duration field carries this number per-request.

Drill-down: group by Equipment Category to find slow-MTTR categories.

3. Backlog by stage

UI: kanban without any filter, count cards in each column. Healthy distributions:

Stage Healthy backlog
Submitted < 4 h × tickets_per_hour
Pending Review < manager's daily capacity
In Repair scales with tech headcount
Awaiting Pickup should be near zero — ward should collect fast

Awaiting Pickup is the early-warning indicator: when it grows, ward communication is breaking.

4. Per-stage time consumed

UI: audit log → group by To Stage → look at the median Time in Prev Stage. Compare to the seeded SLA:

Stage SLA Healthy median
Submitted 4 h 1–2 h
Pending Review 8 h 2–6 h
In Repair 24 h 8–18 h
Awaiting Pickup 8 h 1–4 h

If your median time in Pending Review is creeping past 6 h week-over-week, the manager triage step is becoming a bottleneck.

Exports for surveyors

The audit log list supports the standard Odoo export (Action → Export → All fields). Recommended export configuration for an HA visit:

Field Why
transitioned_at Date of move
request_id/name Ticket reference
request_id/equipment_id/name Equipment
from_stage_id From
to_stage_id To
transitioned_by_id/name Who
roots_time_in_previous_stage_hours Duration

Export filtered by a date range (e.g., fiscal year), and the resulting XLSX/CSV is the surveyor's evidence file.

What the workflow module does NOT report

  • No trend graphs over time — the audit log is row-per-event; for time-series visualisation use the pivot view or a Layer-4 BI module.
  • No vendor SLA scorecards — that's Q4 service-contracts work (see Service Contracts → Reporting).
  • No mobile dashboards — desktop-first; mobile is on the Q-future roadmap.
  • No per-ward breakdown — maintenance.request carries equipment_id but not a separate ward field. Ward analysis goes via equipment category or a custom field.