A pre-read for the workshop. What the reporting work stream is, why Oakland gates it, and what we know today.
Read it before the workshop so we can dive into meaningful discussion.
Feel free to come with — or pre-send — questions to Dan and Linda. The accompanying worksheet has specific questions to think about before the workshop as well.
02Five parts. Click any section to jump there.
Large courts have built fragile, court-specific reporting workarounds to fill the gap. Oakland's onboarding, JIS's top organizational priority, is gated on a credible reporting solution.
04The following is based on discovery research conducted across five large Michigan courts: Oakland, Kent, Macomb, and Wayne Circuit circuit courts, and D36 Detroit district court.
These findings reflect the reporting landscape at large, high-volume courts specifically. Smaller courts may have different needs and constraints that are not yet well understood.
05A simplified view of the case lifecycle that reporting touches — four phases, each with a handful of sub-tasks.
Reporting is shown here as a downstream step for simplicity, but in practice it is not fully downstream. Operational reports are sprinkled throughout the lifecycle (supporting scheduling, docket management, etc.), while statistical and compliance reports draw from the full lifecycle after the fact.
Drive daily case processing workflows. Staff use them as work queues to determine what needs to be done.
Examples: cases eligible for dismissal, notices that need to go out, docket entries that need correction.
Serve state-required submissions (such as MCAP), quarterly caseload memos, case age tracking, and other measurement and accountability requirements.
Note: confirm whether MCAP is the submission tool or a specific report.
Reports vary along two concepts: timing (when it runs) and type (who built it). Each concept defines a clean binary. On the next slide: how these two concepts combine into three real categories.
Crossing Timing (rows) × Type (columns) produces four quadrants, but only three exist in the wild.
| Standard (JIS Canned) | Custom (Court-Specific) | |
|---|---|---|
| Scheduled | Standard + Scheduled Data Lakehouse → Power BI on a recurring cadence. The core of what the platform serves on MVP. | Custom + Scheduled Court IT-built recurring reports. Platform must distribute these via a parallel path (CMS → mainframe → PDF → report store). E.g. Kent's Crystal Reports on CourtView; D36's Power BI over JIS DCS; Macomb's IT-built SQL reports. |
| Ad Hoc | Doesn't exist in the wild Standard reports are scheduled by nature. Running one "outside its normal schedule" is a UI concern, not a distinct category. | Custom + Ad Hoc Self-service report creation for one-time, investigative needs. E.g. Business Objects at Oakland. Lower priority for MVP. |
The distribution platform must handle both quadrants on the Scheduled row — Data Lakehouse for standard reports, and a parallel CMS-originated path for custom reports. Ad hoc self-service is real but lower priority for MVP.
Today, large courts have built their own reporting workarounds to support the scale of their high-volume caseloads and operational needs.
These solutions are fragile, court-specific, and dependent on institutional knowledge that walks out the door when key staff leave.
There is no shared reporting infrastructure across courts, no standard way to generate or distribute reports, and no path for courts onboarding to JIS to maintain their current reporting capabilities on the new platform.
One representative snapshot per court. Same problem (CMS canned reports don't do enough), radically different workarounds — shaped by volume, staff capacity, vendor choices, and institutional knowledge.
These are snapshots, not full pictures. Each court has many more workarounds than the one shown here — the detail lives in the individual court summaries. The takeaway: there is no shared reporting infrastructure, and no two courts have converged on the same solution.
Oakland County is JIS's highest-priority onboarding target. They have explicitly stated that functional parity with their current reporting capabilities is a condition of JIS adoption.
If the MiCourt Platform can't match Oakland's reporting at minimum, Oakland won't move.
Oakland operates five reporting channels, but they have a clear priority order. The MVP needs to match the first one. The rest are supporting context.
Java-based web service hosting 137+ automated reports with Okta SSO, tiered retention, department-level access control.
Reports are inflexible: the format, data, filters, and parameters are all pre-determined. The main system that needs feature parity in MiCourt.
Flexible ad hoc analytics with merged data universes. Users can drag and drop fields in real time to define the report they need, essentially a Power BI sandbox.
Serves investigative needs that cross source systems.
Lower priority, but part of Oakland's current landscape.
Heavily mainframe-dependent. Reports generate as PDFs stored on disk; two distribution channels (Oak Reports + Business Objects); users retrieve, view, and save manually.
Standard reports flow through the JIS Data Lakehouse + Power BI; custom Oakland reports continue to generate via the mainframe. Both paths converge at a single Report Store, which AO's Platform Reporting layer sits on top of.
Large courts need reports both to do their daily work and to meet their compliance obligations. Oakland's onboarding, JIS's top organizational priority, is gated on a credible reporting solution.
16Reporting is one of six work streams in the 2026 Platform Enhancement contract, but it has outsized strategic importance because it directly gates Oakland County onboarding. Oakland onboarding is JIS's top organizational priority.
JIS's goal is a statewide, unified, web-centric court case lifecycle management system. A scalable reporting solution is infrastructure that every court will need as they move onto the platform.
The SOW defines three outcomes.
Define MVP scope, establish collaboration patterns with the JIS Data & Analytics team, and produce a validated roadmap.
Centralized access to automated daily/weekly reports for court staff, integrated with the portal experience.
Prove the solution at lower complexity before taking it to Oakland's scale.
We are the delivery partner responsible for building this, with a 12-month contract window (May 2026 – April 2027) to deliver reporting. We have a stake in the scope and features that get prioritized because we will be on the hook for delivering them.
Walk into the JIS onsite with a defensible point of view on what the MVP should include.
Within the contract timeline.
Push for decisions that set us up to ship.
Genuinely solve Oakland's blockers while remaining scalable to other courts.
Courts range from fully manual to partially automated. The variation is largely the result of courts developing in-house solutions or partnering with alternative vendors to meet their own reporting and operational needs — each independently investing in tools shaped by their volume, staff capacity, and technical resources.
21| Kent County | Macomb County | Oakland County | Wayne Circuit | D36 Detroit | |
|---|---|---|---|---|---|
| CMS | Court View | Court View | JCM | Odyssey | JIS DCS (forked) |
| E-Filing | WebTex Website Solution | MiFile | MiFile | Internal Tools + MiFile | — |
| Document Processing | OnBase | OnBase | OnBase | Internal Tools + OnBase | — |
| DMS | OnBase | OnBase | Laserfiche | Odyssey | — |
| Judge's Bench | App Builder | Smart Bench | Laserfiche | OnBase + Odyssey | — |
| Reporting | Crystal Reports (~100 custom) | CourtView (print-to-Excel) | Oak Reports, Business Objects, CICS, JOS spool, Laserfiche | WebFocus (scheduled + email) | JIS DCS native reports, Power BI (over text exports) |
| Court | Maturity | Headline |
|---|---|---|
| Oakland | Most mature | 137+ automated reports via Oak Reports; process-driven automation for orders; no self-service; once-daily data refresh lag |
| Wayne Circuit | Partially automated | WebFocus pushes scheduled reports via email; not prioritized for JIS onboarding |
| Kent | Self-serve but manual | ~100 Crystal Reports maintained by one IT person; strong preference for human review before distribution |
| D36 Detroit | Scale-broken | Reports take 4–5 hours; 787+ saved with no search; queue prioritization issues; quarterly compliance report sometimes arrives same day it's due |
| Macomb | Fully manual | Every report requires print-to-Excel; quarterly memo takes nearly a full month; judge rules in handwritten notes |
Process-driven automation generates scheduling orders, show cause orders, and dismissal orders automatically. Business Objects serves ad hoc analytics needs with merged data universes spanning CMS, prosecutor, jail, and pre-trial data.
Oak Reports uses Okta SSO with tiered retention and department-level access control. Oakland has requested a three-tier access model for MiCourt — the most granular access model of any court:
No on-demand self-service capability, and the system relies on once-daily data refreshes that create operational lag.
WebFocus generates scheduled reports and pushes them via email. Automated email distribution of reports is of interest across courts.
Wayne Circuit is not particularly interested in onboarding to JIS, and they are not a priority for JIS either. They are functional independently as-is, and onboarding Wayne Circuit is not in the current roadmap.
~100 custom Crystal Reports built and maintained by a single IT person, with same-day turnaround on new requests. No automated generation or distribution.
Kent briefly tried automated email delivery but reverted after one report went out with incorrect information. That experience created a strong preference for human review before any automated distribution.
JIS's native reporting infrastructure fails at D36's volume. Reports that should take minutes take 4–5 hours. 787+ saved reports with no search capability.
Power BI is layered on top of text file exports as a fragile workaround. Staff run six separate reports and stitch them together in Power BI to get the view they need.
JIS has prioritization coded into the report queue based on document type, not timeliness or deadline. D36 cannot see, review, or change how reports are prioritized. When a lower-priority report is actually urgent, staff must contact in-house IT to manually jump the queue.
The quarterly compliance report sometimes arrives the same day it's due.
Macomb is fully manual. CourtView reports render as garbled characters on screen. Every report requires print-to-Excel-to-manual-formatting.
The quarterly caseload memo takes nearly a full month.
Per-judge variability is the highest observed. Judge-specific rules live in handwritten notes and tribal knowledge rather than in any system.
Staff use reports to join data the CMS stores in separate tables or systems. D36 stitches six reports in Power BI. Kent runs ad hocs to catch CMS errors. Oakland merges CMS, prosecutor, jail, and pre-trial data.
Oakland staff use daily reports as task lists. Kent clerks treat reports as assigned job duties. D36 analysts drive their entire workflow from report output.
Wayne already has it. Oakland has automated generation but not automated email distribution. Kent, Macomb, and D36 have none. Every court without it wants it first.
Kent's experience with one incorrect automated email created lasting distrust. Across courts, staff expressed a clear preference for a review or approval step before reports are distributed broadly.
Every judge does things differently. Financial rules, notice preferences, scheduling timelines, distribution lists — all vary by judge.
Every court depends on one or two IT people. Self-serve — or even configurable parameters — would reduce bottlenecks everywhere.
Clerk's office, case management, records/abstracting, financial/fines, scheduling. They pull daily or weekly reports and feed them into other business processes.
Not technical. Don't want to build reports. They want to open a hub, find their report, get to work.
Senior clerks, supervisors, designated power users. They own specific reports, grant and revoke access, decide who sees what and how long reports are retained.
Oakland has requested a three-tier access model (JIS → court power admin → department admin → individual user) — the most granular version of this persona.
Two audiences adjacent to the reporting platform — relevant to think about, but not the MVP's primary focus.
Consume reports but don't generate them. Motion call packets assembled for judges and routed to DMS. Some prefer print, some prefer PDF. Judge-level distribution and formatting preferences must be configurable.
Power users who need one-time, investigative reports, often joining data across systems. Currently served by Business Objects (Oakland) or IT-mediated custom queries. Real persona, but out of scope for MVP.
This team manages the data lakehouse and has made a set of standard reports available as embedded Power BI on the web. The SOW calls out establishing collaboration patterns with them — we haven't yet.
The Data & Analytics team is only one source of report creation. They are not in the business of recreating all of each court's reports. Some custom Oakland reports will continue to be generated through their existing upstream process (CMS → mainframe) and will need to be distributed by the platform without being recreated in the Data Lakehouse.
→ Two things we don't know that shape everything downstream — see next slide.
35Both shape everything downstream in the reporting work stream.
We don't yet know the full set of standard reports the D&A team has made available. That gap shapes what the MVP can surface on day one. Some of Oakland's current Oak Reports may overlap with standard JIS reports already supported by the Data Lakehouse; some will not.
| Mode | What it looks like | Complexity |
|---|---|---|
| One-directional | Surface standard reports; users interact via built-in Power BI filters and date pickers | Straightforward |
| Bi-directional | Users can edit or create reports initiated from MiCourt Platform beyond standard interactions | Significantly more complex |
Bi-directional means a report creation request flows from the platform back into the data source (whether the Data Lakehouse or another source) and a new report is then generated and served back up. This only applies to Data Lakehouse-served reports; custom reports generated upstream via mainframe/PDF are not editable through this path.
This decision sits between us, the D&A team, and Oakland's expectations. It is the single biggest scope lever in the reporting work stream.
Oakland has expressed interest in creation, editing, real-time data, and downstream workflow triggers. Each is reasonable in isolation; collectively they dwarf the contracted scope.
JIS is moving toward a groups-and-roles model while Oakland has requested more granular, department-level control. Resolving this gap early will help avoid design rework later.
Additional discovery is needed on how reports are used in workflows to validate that output supports downstream business processes. Court users will want to say "can we automate this?" — closely related to scope management.
Agree on MVP scope and manage scope creep for potential incremental or unique differences between departments.
We need a plan for environment and data setup to ensure different types of reports, formats, and filter needs are supported — and that software doesn't unintentionally break reports. Access to "real" Oakland reporting as controls? Small courts' replicated data?
We need clearly identified points of contact across JIS teams. Atomic Object's access to Oakland will be managed through JIS.
Risk of implementing a solution highly targeted to Oakland specs that will need to get reworked for other courts. Opportunities early to do additional light discovery with other courts, or include in the pilot?
Check the accompanying worksheet for specific questions to think about before we meet. Feel free to pre-send questions to Dan and Linda.
3802-discovery/summaries/Reporting-Court-Synthesis-draft-2.0.md01-handoff/Oakland_Platform Reporting.md2026-03-19_oakland-automated-reports-design-review.mdIf you don't have access to these sources, ask Linda or Dan and we'll share them with you.
39