Background
The ‘integration transaction record (ITR)’ process allows third-party organisations - specifically Capita (Teachers' Pensions) and the Education Workforce Council (EWC) for Wales - to share their records with the database of qualified teachers (DQT). This ensures that the data between these organisations and DQT is aligned.
We needed to design functionality to help staff:
- monitor data imports from these organisations - specifically Capita (Teachers' Pensions) and the Education Workforce Council (EWC) for Wales
- act when records failed to import correctly
While API integrations are expected from summer 2026 when Teachers’ Pensions changes suppliers, this work supports the existing spreadsheet-based process used during the transition.
Our goal was to help users easily:
- check whether a data transfer completed successfully
- view any data fields that failed to import
This enables staff to identify issues and inform third-party organisations of any changes needed.
Initial designs
For this feature, we based our initial designs on the Microsoft Dynamics interface that users access data through, using patterns and language they’re familiar with.
Interfaces page
The interfaces page displays columns labelled:
- ID (an internal reference number)
- Interface (who the data came from, for example Capita)
- Date (when the import happened)
- Upload time
- Duplicates (whether an imported record matches an existing record in DQT)
- Failures (whether any data failed to transfer correctly)
Each value in a row is a link that takes the user to that specific interface.
File details page
The file details page features a summary of the record at the top of the page with the labels:
- File name
- ID
- Total count (the number of rows in the spreadsheet)
- Success count (the number of rows that were imported correctly)
- Failure count (the number of rows that failed to import correctly)
- Duplicate count
Below the summary, we show a sortable table with the columns labelled:
- Row ID (the row number in the spreadsheet)
- Person (the record holder)
- Duplicate
- Status (whether the row imported correctly or not)
- Created on (when the import happened)
We display failed imports first by default.
Each value in a row is a link that takes the user to a page showing the details for that row.
Row details page
On the row details page, we show:
- Row ID
- Status
- Row data
- Failure message (if any)
- Duplicate status
User testing
We tested the designs (opens in Lucid) with TRA support team colleagues to understand how well they met their needs.
The sessions didn’t raise major concerns, but provided useful insights for improving the designs, including:
Interfaces page
Users found it unclear that the entire row was a clickable element. They expected each link to take them to a specific detail of the import (for example, the upload time), rather than the file details page.
Showing the upload time isn't useful. Users would prefer to see the total, successes and failures at this level, noting that if the successes and failures don’t match the total, there might be an issue with the upload.
“It’s handy to see the total count, the success count and the failure count to make sure it all adds up.”
One user said that multiple entries can occur per day if a rerun is needed after an error, so a timestamp would be useful.
They also suggested that the ‘Capita Export’ and ‘Capita Amend’ filenames be changed to ‘Capita Export New’ and ‘Capita Export Amend’ respectively to reflect their content.
“I would expect it to be ‘Capita Export New’ and ‘Capita Export Amend’. ‘Capita Export New’ is all the previous day’s allocation of TRN. ‘Capita Export Amend’ files would be any record where the record has a National Insurance number added or amended.”
File details page
The ‘Created on’ column shouldn’t be necessary as that information is already on the Interfaces page.
Users wouldn’t expect to ‘Duplicate’ on a failure.
Users preferred having all failure information in one place rather than having to click into each row.
“I would want to be able to pull out all these failures to see what they are. I wouldn’t want to go through them individually. We can currently pull out a spreadsheet to see all the failures together.”
Again, it wasn’t clear that each row was a single clickable element.
Row details page
Users were happy with the information on the page but missed that the error was separate from the duplicate status.
“It makes sense. I can the row data, I can see the failure and it says it’s a duplicate.”
Iterations
We made the following changes based on user and developer feedback:
Interfaces page
We:
- made the interface value the only link in a row
- added a timestamp to the date
- removed the upload time column
- added the total, successes and failures columns
- updated interface names to ‘Capita Export New’ and Capita Export Amend’
- added an ‘Import status’ column to show whether an import succeeded or failed, using green ‘Success’ and red ‘Failure’ tags
File details page
We:
- put the summary into a summary list component
- made the person’s name the only link in a row
- added the date and time to the summary and removed the ‘Created on’ label from the table
- added an ‘Export failures’ button
- designed an error message to show if an upload was unsuccessful
Row details page
We removed the Duplicate label if there was a failure.
Content consistency
The designs we tested used different labels for the same data across pages - for example ‘Date’ and ‘Created on’ or ‘Successes’ and ‘Success count’.
We updated the labels to use consistent terminology throughout to make things clearer for users.
Prototype
View final designs in the prototype (password: tra)
Screenshots
View of DQT in Microsoft Dynamics
Interfaces
File details
Row details
Unsuccessful upload error message
