Student records forum 07/05/25

Hi all,

Massive thanks to everyone that was able to take part in the student forum discussion, very excited for the next round of forums. 

Great questions and ideas raised as well as constructive feedback on the mock-ups shared, that has given us some great ideas to look at implementing.

Please see below for our points captured during the meeting, and feel free to comment to this board with any additional thoughts/suggestions

Many thanks,

Harrigan

SPA: Student Profile Changes 

•    Bulk edit student records option: outside of the existing bulk edit fields options, suggestion raised was to create a spreadsheet based bulk edit feature, whereby selected students would appear on screen with fields from the record. Any changes made on the excel would then be imported back into the system, updating the relevant student records

•    Suggestion for more custom tabs to be made available on student records, and for the field options here to have the same/more field type options as the existing event log feature

•    Suggestion to be able to open multiple student profiles and manoeuvre between rather than go back and forth from main student list – or just manoeuvre through your group of students once filtered down, same for staff. Suggested that the options that appear at the bottom of the mock-up currently to switch between tabs within a record, would be better suited to instead switch between student records (based on order of appearance from the student list screen). The search bar at the top of student records to navigate to other students also a well received option.

•    Select All students and migrate to next year group: suggestion for bulk update to be made available for this, and a further improvement here would be for this to be automated

•    Subject access request function: download everything in one swift move – to be implemented via a specific export function

•    Start Dates, planned dates, site record date, leaving reason, applies to whole student record rather than site record. 

•    Crossover between student record and care plan data. A lot of duplicated data can the Care Plan link to profiles more easily. Student disabilities and support moved away from tabs and re-created on care plan. 

•    Suggestion for an ILR tab that displays all ILR related fields in one area. Alternative also suggested to mark fields with indicator to know which fields are ILR fields. Difficult to pull data from multiple student tabs to build the ILR. Any changes to values on this tab to also update on the ILR screen and any other relevant fields on the student record, and vice-versa.  

- Same functionality for the census return. 

- The ILR tab would not replace the grid, as the ILR grid gives a good overview of multiple students

- ILR grid: being able to filter which columns appear on-screen. 

•    Suggestion for a relationship between the student record and the funding areas, to avoid repeated inputs between the 2 areas. As an example, a link to the daily tab so you don’t have to repeat inputs. 

•    Suggestion for site record start date to include validation when entering learning aims so that the learning aim start date can’t be before the start date of the student. Suggestion for the default Learning Aim start date to be the Site record start date – after further discussion, suggestion for this to be prompt based was discussed to avoid any unexpected errors. 

•    Suggestion for mandatory field checks to also cover ILR/Census required data – after discussion, there was the potential issue of this preventing records from being created when trying to add student applications/enquiries – an alternative offered was to have a second mandatory field check in place – this could work well with the ILR/Census specific student record tabs, where any ILR/Census mandatory fields could be checked from. (For full visibility, this same principle should be applied to any ILR/Census screens when showing multiple student’s data).

•    Request for more validation for the relevant fields on a student record – for example, mobile fields can only have numbers, postcodes should follow a specific format (if UK based). Validation is a key consideration when designing screens and will be included throughout the DB3 design process.

•    Pre-defined fields – suggestion to be able to toggle these on/off so we’re not displaying fields that aren’t in use. 

•    Question raised around possibility to display fields/tabs depending on the status of the student. Enquiry students only needs certain fields, an application only needs certain fields, day students different to a residential. We have currently planned to show/hide fields based on site type (eg. College/school/residential/non-residential), but will investigate options for further customisation here. 

•    Suggestion around Staff Links: any staff links should also be displayed on staff records to provide an easier way to track/update staff links, from either the student or staff records. 

•    Positive reception to planned changes regarding how to track historic properties of site details fields, such as the department/group/staff links.

•    Student documents – Suggestion raised to be able to limit permissions based on a staff link/role rather than a user group, as this allows for more granular security setting. 

•    Student documents - suggestion for a tagging system for documents, similar to existing categories options for easier filtering. Suggested improvement would be to take the existing category options and include the ability to add sub-categories to create this second tier.

•    When explaining about our plans for any student documents to also be editable directly from Databridge, rather than download them, this was well received, however an important question was raised around how any changes made to these documents would be tracked – this is currently still under investigation. I do have confirmation that it is likely for any historic versions of files to also be accessible if required.

DB3 Student List

•    Suggestion that the splash screen on the student list screen should be customisable, as different data is relevant to different provisions. An options menu (similar to the existing System policies area) to toggle different fields on/off for the splash screen would be the ideal.

•    Discussion around how the mobile view will differ from the desktop view – throughout the design process we are considering both mobile and desktop view to format screens in the most user-friendly manner

•    Suggestion raised that when setting up the custom splash screen, have options to say whether it should be shown on PC, mobile, or phone. 

•    Worry of load time of new student card list – Answer: currently fine, but if customers want custom splash pages, then yes, could be an issue. Particularly with student profile photos appearing and the increased loading times here.

•    Specific request that the total number of students shown based on filters to be displayed on the list screen – this is already planned for implementation, but wasn’t included on the drafted mockup shared during the meeting

•    For mobile users the card information could be a lot: prefer the list view. 

•    Lot of info on mockup student list cards that aren’t relevant, and pagination raised as an issue. Question around how editable is this, as you don’t want to have to move between pages 1-10. If we do opt for pagination to decrease loading times, we would need to also include default settings for each user to determine how many records load as a default (this would be covered in the ‘My defaults’ equivalent on DB3.)

•    Suggestion to be able to save presets of filters to the student list screen, and to be able to set default filters. 

Thanks again to everyone that was able to attend, and looking forward to seeing you at the next one on the 14th!

0 Votes