A structured view of every integration point between the four case management platforms identified during the scoping phase — including formal technical integrations, shared infrastructure dependencies, external agency connections, and the manual bridges built at the seams between systems.
Points where a case moves from one platform to another — either formally via integration, or informally via manual handoff. These are the transitions most likely to create user confusion and operational overhead.
Criminal cases that proceed to appeal move from the Criminal & Regulatory platform to the Civil Litigation platform. Appellate proceedings at the Supreme Court are managed in System A, while the originating case record remains in System B. The handoff requires case files, documents, and hearing history to be accessible across systems — currently managed through operational coordination rather than automated integration.
Criminal matters — particularly domestic violence, youth offences, and certain regulatory cases — can trigger family proceedings (care orders, protection orders, maintenance applications) that are managed in System C. The reverse also occurs: family proceedings can reference criminal records. The two systems share deployment infrastructure (EDS) but have no formal case linking capability.
Some civil cases — particularly probate, mental capacity applications, and certain matrimonial property matters — have family dimensions that require coordination with the Family platform. The Civil platform handles the legal filing; the Family platform manages the welfare and relationship aspects of the same matter.
Data that all four platforms consume but that no single platform owns. Each system maintains its own copy, manually synchronised. These are the highest-risk gaps for a modernisation programme because they represent coordination overhead that sits outside any single system’s scope.
Room availability, hearing quotas per court type, and public holidays are used by all four platforms for hearing scheduling. There is no master data source for any of this — each platform maintains its own copy. Updates (new holidays, changed room availability, quota adjustments) must be manually applied to each system independently. Conflicts between systems require manual resolution by administrative staff.
Users who work across multiple platforms — senior judicial officers, registry staff, court officers — must be provisioned and managed independently in each system. Each system defines its own role matrix. There is no unified authorisation layer. A change in a user’s responsibilities requires manual updates across every system they have access to.
Connections from the four platforms to external government systems and agencies. Each integration was built independently; no shared integration layer or common API pattern exists.
A prioritised view of integration risks that the discovery phase should investigate — either through user research, technical deep-dives, or programme-level stakeholder alignment.
| Integration Point | Risk Level | Type | Why it matters for the programme |
|---|---|---|---|
| Shared calendaring data (no system of record) | High | Shared data gap | Affects all 4 systems. Cannot be fixed within any single system’s scope. Requires a programme-level data ownership decision before any scheduling modernisation can proceed. |
| Appeals cross-system flow (B → A) | High | Cross-system case flow | Changes to either system’s data model or document management capability must account for this dependency. A modernised System B that changes case identifiers or document structures will break the appeals handoff to System A. |
| Shared deployment infrastructure (B + C) | High | Infrastructure coupling | Systems B and C cannot be modernised independently without first decoupling their deployment. Any sequencing plan that treats them as separate workstreams must account for this. |
| User role matrix fragmentation (all systems) | Medium | Shared data gap | Multi-system users experience role inconsistency. Automated cross-system workflows are impossible without a unified authorisation model. This is a prerequisite for the Platform Layer of the transformation model. |
| 30+ agency integrations (System C) | Medium | External integration | Each integration is independently maintained. Modernising System C without a shared integration layer means rebuilding each agency connection individually. Significant effort, and a pattern that won’t scale to future agency additions. |
| Payment gateway and fee structure misalignment | Medium | Shared service | Fee structures are misaligned across platforms but all flow through the same gateway. Harmonising fees requires business alignment across court divisions before any technical changes can be made. |
| Criminal-family cross-domain proceedings (B ↔ C) | Medium | Cross-system case flow | Users handling cross-domain cases currently navigate two systems without a unified case view. Discovery should surface how frequently this occurs and what the user experience cost is — this may be a higher priority than it appears in system documentation. |
| Redundant notification gateways | Low | Shared service | Functional but inefficient. Gateway consolidation is a maintenance and cost optimisation, not a user experience priority. Can be addressed as part of Platform Layer work without urgency. |