Judicial Itineraries (JI) - Integration Dependencies
This document maps the integration flows between the Judicial Itineraries (JI) system and external systems, describing what data moves, how it moves, and who is involved at each step.
At a Glance
| # | Flow | Source | Destination | Data | Mechanism | Frequency | Criticality |
|---|---|---|---|---|---|---|---|
| 1 | Judge Master Data | eLinks, HR Records | JI | Judge profiles, working patterns, contractual sitting days | Manual entry / manual copy | On change | High |
| 2 | Planned Activity Capture | Court Listing Systems | JI | Planned sittings, work types, daily judicial activity | Manual copy into JI | Daily | Medium |
| 3 | Sitting & Booking Confirmation | Court Staff | JI | Confirmed sittings, actual work types, session durations | Manual entry via JI UI | Daily | High |
| 4 | Absence & Vacancy Management | Courts, RSU | JI | Absence requests, vacancy creation, NTBF decisions | Manual entry via JI UI with approval workflow | Event-driven | High |
| 5 | Fee-Paid Payment Export | JI | JFEPS, Liberata | Payment files for fee-paid judges | Excel export, email, manual upload | Weekly | Critical |
| 6 | Payment Reconciliation | JFEPS | JI | Payment confirmations, discrepancies | Manual flagging in JI | Ongoing | Medium |
| 7 | Management Information & Reporting | JI | DA&I | Sitting days, utilisation, vacancy/absence analysis | Excel / PDF report exports | Reporting cycles | High |
| 8 | Notifications & Communications | JI | HMCTS Email, Judges, Court Staff | Itineraries, booking confirmations, absence alerts, payment files | Automated email (some batch) | Event-driven | High |
Flow Index
- Judge Master Data (eLinks / HR -> JI)
- Planned Activity Capture (Listing Systems -> JI)
- Sitting & Booking Confirmation (Court Staff -> JI)
- Absence & Vacancy Management (Courts / RSU -> JI)
- Fee-Paid Payment Export (JI -> JFEPS -> Liberata)
- Payment Reconciliation (JFEPS -> JI)
- Management Information & Reporting (JI -> DA&I)
- Notifications & Communications (JI -> HMCTS Email)
Flow 1 -- Judge Master Data (eLinks / HR -> JI)
Judge profile and working pattern data originates in external HR systems and the eLinks Judicial Database, and is manually entered into JI by RSU users. JI is not the system of record for judge employment data; it reflects what has been agreed elsewhere.
| Attribute | Detail |
|---|---|
| Sources | eLinks (Judicial Database), HR / administrative records |
| Destination | JI (Manage Judges screens) |
| Data | Judge names, titles, contact details, judge type (salaried / fee-paid), base location, roles, authorisations, tickets, working patterns (days, locations, work types), contractual sitting days, part-time arrangements, jurisdictional split, retirement dates, payroll numbers, fee payment status |
| Mechanism | Manual entry by RSU / judicial team users. The SRS states an eLinks integration requirement (NFR-3: "The system shall support eLinks integration for importing judiciary data") but the technical mechanism is not implemented. |
| Frequency | On change -- new judge onboarding, base court transfers, part-time conversions, role updates |
| Users involved | RSU Admin, Regional (Full Access) users |
| Criticality | High -- all itineraries, bookings, and reports depend on accurate judge data |
Source: ./flow-1-judge-master-data.mmd (Mermaid). Regenerate with mmdc -i flow-1-judge-master-data.mmd -o flow-1-judge-master-data.png -b white -s 3.
Gap: There is no automated synchronisation. Users must manually keep both eLinks and JI updated. The training documentation notes this will be revisited once the Judicial Database replacement is complete.
Flow 2 -- Planned Activity Capture (Listing Systems -> JI)
Data on how judges plan to spend their working day is sourced from court listing systems and entered into JI manually. There is no direct integration with case management systems (CaseMan, FamilyMan, Common Platform).
| Attribute | Detail |
|---|---|
| Source | Court listing systems |
| Destination | JI (Sittings, Judge Itinerary screens) |
| Data | Planned sittings, work types (Crime, Civil, Family, S9, Off Circuit), session durations (full day / half day AM/PM), sitting locations |
| Mechanism | Manual copy from listing systems into JI by HMCTS court staff. Ad-hoc sittings can also be created directly in JI. |
| Frequency | Daily (progressive entry recommended) |
| Users involved | Court (Full Access), Regional (Full Access) |
| Criticality | Medium -- feeds into utilisation reporting once confirmed |
Source: ./flow-2-planned-activity-capture.mmd (Mermaid). Regenerate with mmdc -i flow-2-planned-activity-capture.mmd -o flow-2-planned-activity-capture.png -b white -s 3.
Gap: No system-to-system integration exists. The documentation explicitly states no direct integration with CaseMan, FamilyMan, or Common Platform.
Flow 3 -- Sitting & Booking Confirmation (Court Staff -> JI)
After a sitting or fee-paid booking occurs, court staff confirm it in JI -- verifying that it took place, recording the actual work type, and adjusting the session duration if needed. Confirmed data drives both payment processing and MI reporting.
| Attribute | Detail |
|---|---|
| Source | Court staff (local knowledge of what actually happened) |
| Destination | JI (Sittings, Fee-paid Bookings screens) |
| Data | Confirmation status (confirmed / cancelled / rejected), actual work type, actual session duration, verifier sign-off (County Courts) |
| Mechanism | Manual entry via JI UI. Sittings can be confirmed individually or in bulk. County Courts have an additional verification step by a senior manager. |
| Frequency | Daily (strongly recommended), at minimum before monthly verification deadline |
| Users involved | Court (Full Access), Court (Enhanced CJ), Regional (Verifier) |
| Criticality | High -- unconfirmed bookings cannot be exported for payment; unconfirmed sittings are excluded from MI |
Source: ./flow-3-sitting-booking-confirmation.mmd (Mermaid). Regenerate with mmdc -i flow-3-sitting-booking-confirmation.mmd -o flow-3-sitting-booking-confirmation.png -b white -s 3.
Note: Accuracy of confirmation directly affects payment correctness. The training documentation emphasises that "the accuracy of the payment schedules sent to Liberata is highly dependent on the checking that goes on here."
Flow 4 -- Absence & Vacancy Management (Courts / RSU -> JI)
Absence recording triggers a multi-step workflow involving court staff, RSU judicial teams, and vacancy/booking management. This is an internal JI workflow with human actors at each step.
| Attribute | Detail |
|---|---|
| Actors | Court staff (requesters), RSU / Judicial Team (approvers), Court staff (vacancy decision) |
| System | JI (Absences, Vacancies, Fee-paid Bookings screens) |
| Data | Absence type, dates, NTBF status, vacancy requirements, fee-paid judge allocations, booking confirmations |
| Mechanism | Multi-step approval workflow within JI UI. Email notifications at each stage. |
| Frequency | Event-driven |
| Criticality | High -- drives vacancy creation, fee-paid bookings, and downstream payments |
Source: ./flow-4-absence-vacancy-management.mmd (Mermaid). Regenerate with mmdc -i flow-4-absence-vacancy-management.mmd -o flow-4-absence-vacancy-management.png -b white -s 3.
Flow 5 -- Fee-Paid Payment Export (JI -> JFEPS -> Liberata)
This is the most operationally critical integration flow. JI generates payment files from confirmed fee-paid bookings and routes them through a human approval chain to the finance system and payment processor.
| Attribute | Detail |
|---|---|
| Source | JI (Payments screen) |
| Destinations | JFEPS (finance system), Liberata (payment processor) |
| Data | Judge details, payroll numbers, court codes, sitting dates, session types (full/half day), booking IDs, work types, fee amounts, London weighting |
| Format | JFEPS-compatible Excel file |
| Mechanism | JI validates data (dates, court codes, booking IDs) -> generates Excel -> emails to Payment Authoriser -> authoriser reviews and forwards to Liberata -> authoriser uploads to JFEPS |
| Frequency | Weekly |
| Users involved | RSU / Judicial Team (generates schedule), Payment Authoriser (reviews and forwards) |
| Criticality | Critical -- Crown Courts rely on this as the only mechanism to pay fee-paid judges without manual individual payments |
Source: ./flow-5-fee-paid-payment-export.mmd (Mermaid). Regenerate with mmdc -i flow-5-fee-paid-payment-export.mmd -o flow-5-fee-paid-payment-export.png -b white -s 3.
Note: JI does not hold bank details or process payments directly. Sensitive financial data remains in JFEPS and Liberata. Double-submission is prevented by tracking which bookings have been exported.
Flow 6 -- Payment Reconciliation (JFEPS -> JI)
After payments are processed, finance users reconcile the results back into JI to track which payments succeeded, which are pending, and flag discrepancies.
| Attribute | Detail |
|---|---|
| Source | JFEPS / Finance System (payment confirmations) |
| Destination | JI (Payment Reconciliation screen) |
| Data | Payment status (paid / pending / queried), reconciliation notes, discrepancy flags |
| Mechanism | Finance users manually check JFEPS payment confirmations, then flag payments as reconciled in JI. No automated data feed from JFEPS back to JI. |
| Frequency | Ongoing as payments are processed |
| Users involved | Finance / Payment Authoriser |
| Criticality | Medium -- prevents double-payment and surfaces discrepancies |
Source: ./flow-6-payment-reconciliation.mmd (Mermaid). Regenerate with mmdc -i flow-6-payment-reconciliation.mmd -o flow-6-payment-reconciliation.png -b white -s 3.
Gap: Reconciliation is entirely manual. There is no automated feed from JFEPS back into JI. Finance users must cross-reference two systems.
Flow 7 -- Management Information & Reporting (JI -> DA&I)
JI is the primary source of sitting day data for Civil, Family, and Crown Courts. DA&I extracts this data for management information, performance reporting, and strategic decision-making.
| Attribute | Detail |
|---|---|
| Source | JI (Reports screens) |
| Destination | DA&I team systems, senior leadership, ministers |
| Data | Sitting day summaries, judicial utilisation, vacancy analysis, booking analysis, absence/official business analysis, jurisdictional splits, work type distributions |
| Format | Excel and PDF exports from JI report screens |
| Mechanism | Export-based -- users run reports in JI, copy/paste or download to Excel/PDF. DA&I then transforms and aggregates. Manual extraction via spreadsheets also used. |
| Frequency | Aligned to reporting cycles (monthly, quarterly, annual) |
| Users involved | MI / Reporting Users, DA&I analysts |
| Criticality | High -- ministers require performance reporting across jurisdictions; JI is the primary data source for courts |
Source: ./flow-7-mi-reporting.mmd (Mermaid). Regenerate with mmdc -i flow-7-mi-reporting.mmd -o flow-7-mi-reporting.png -b white -s 3.
Gap: Tribunals data is not captured in JI. Tribunal sitting data is collected manually via spreadsheets managed by different Chamber Presidents' Offices, leaving a significant gap in cross-jurisdictional reporting.
Flow 8 -- Notifications & Communications (JI -> HMCTS Email)
JI uses HMCTS email infrastructure as a transport layer for operational notifications, itinerary distribution, and payment file delivery.
| Attribute | Detail |
|---|---|
| Source | JI (various screens) |
| Destination | HMCTS email infrastructure -> judges, court staff, RSU, Payment Authorisers |
| Data | See trigger table below |
| Mechanism | Automated email from JI. Some emails are sent immediately on action; others (e.g. booking acknowledgements) are batched via an overnight process. |
| Frequency | Event-driven |
| Criticality | High -- operational communications depend on email delivery |
Email triggers:
| Trigger Event | Recipients | Content |
|---|---|---|
| Booking created | Fee-paid judge | Booking confirmation with dates, court, work type |
| Booking cancelled / rejected | Impacted judge and court staff | Cancellation notification |
| Absence confirmed | Judge | Absence acknowledgement |
| Itinerary updated | Judge and relevant staff | Updated itinerary |
| Payment schedule generated | Payment Authoriser | JFEPS-compatible Excel file attached |
| Sitting/booking changes | Court staff | Alerts within system and optionally via email |
Source: ./flow-8-notifications.mmd (Mermaid). Regenerate with mmdc -i flow-8-notifications.mmd -o flow-8-notifications.png -b white -s 3.
Key Observations
No API integrations exist. Every integration is either manual data entry, file-based export (Excel/PDF), or email. This limits automation and introduces data quality risks from manual transcription.
The payment flow is the most critical end-to-end integration. It spans four steps (confirmation -> export -> authorisation -> payment) with human checkpoints at each stage. Any delay in court confirmation cascades into delayed payments.
eLinks integration is aspirational, not operational. The SRS records it as a non-functional requirement, but no automated data exchange is implemented today.
Reconciliation has no return feed. Payment outcomes from JFEPS are not automatically reflected in JI. Finance users must manually bridge the two systems.
Tribunals are a blind spot. JI has no integration with Tribunal listing or scheduling systems. Extending coverage to Tribunals (Employment, Immigration & Asylum, SSCS) is a stated strategic priority.
Future integration pressure. The Actuals programme and Scheduling & Listing (S&L) reforms both require JI data. The current export-only model will not scale to support these needs.
Source Documents
This analysis is based on the following input documents:
- High Level Capabilities JI.docx
- JI Functional and Non Functional Requirements.docx
- Judicial Itineraries High Level Requirements.docx
- Judicial Itinerary KB.docx
- OPT JI Training Brief DRAFT 02.doc
- UCD resource request.docx
Source: docs/architecture/asis/integration-dependencies.md