Implementation of the new engagement tool aligns with the University’s strategic aim of ‘Providing an education that empowers’. Check-In will provide real-time data and insights to help departments prioritise welfare and wellbeing support and offer a more personalised approach to students. It will also help us to meet UK Visas and Immigration (UKVI) compliance requirements.

We care a lot about engagement at the University. The majority of departments are already capturing engagement information in various formal and informal ways; however our current processes are not aligned and we are out of line with the sector. A new single system will help to provide clarity and consistency for all staff and students. 

We are capturing attendance for all teaching-based sessions. Lectures are calculated alongside the engagement data for Check-In and form part of the wider Academic Engagement and Wellbeing Procedure.

We want to give students every opportunity to meet the baseline engagement expectations. It is important that students have a number of opportunities to engage with their studies (through lectures, seminars, labs, summative, open and closed assessments, meetings with academic supervisor etc), particularly for those programmes that have a lower number of contact hours.

The focus of the project is on student welfare and wellbeing and the intention is to look at each student case in context, with the full understanding that lectures are recorded and students may not be required to attend.

We understand that there may be other factors, such as a Student Support Plan that encourages the use of lecture capture, but that’s why this should be taken into account when working the Teaching Blocks, rather than removing lectures as a requirement for all. 

We strongly encourage students to make every effort to attend all timetabled teaching sessions (including practical, workshop and laboratory classes) and, where applicable, placements. There are no plans to make attendance compulsory at lectures; however lectures are included as an engagement point so if students do not attend them, then they may be contacted by their department as part of our overall approach to supporting welfare and wellbeing.

The Student Academic Engagement and Wellbeing Policy requires all students to engage with their course of study via at least two face-to-face on-campus sessions (on separate days) each teaching week for Semesters 1 and 2. For the summer semester, departments/schools are required to schedule three engagement points for PGT students. These could be capstone project supervision, academic supervision and broader pastoral support. This is the baseline expectation and is focused on identifying wellbeing and welfare issues. Departments that choose to operate procedures that go above and beyond this requirement (due to PSRB or other academic requirements) are not required to duplicate both processes.

The engagement points captured in the the procedure include:

• Supervision meetings
• Lectures, seminars, labs and other small group teaching sessions
• All summative, open and closed assessments
• Placement reports

Check-In is capturing attendance at on-campus teaching sessions in the first phase of the system roll out. We will look to include additional engagement points in phase 2 and will engage/consult with colleagues to determine the most appropriate aspects of the student experience that we would like to monitor.

Online study is not part of phase 1 but will be considered as part of future phases of the project.

Certain programmes are initially exempt from using Check-In as we cannot meet the detailed requirements needed in phase 1 of the project; however we hope to bring in these programmes in later phases once policies have aligned and we can meet the PSRB requirements. We have consulted with the Chair of Professional Programmes Forum. Following this feedback we reached out to Programme Leaders (represented on that group) on whether they wish to be included in phase 1, where practicable.

The Check-In tool will help to mitigate the corporate risk to the University’s UK Visas and Immigration (UKVI) licence to sponsor students, and will be used to gather consistent engagement data at physical events. Students who hold a Student visa will follow exactly the same process for registering their engagement at events as all other students.

UTC recently approved the revised Policy on Taught Student Supervision to support the transition to semesters and to align with the new Student Academic and Engagement Policy. The core policy changes for 2023/24 are as follows:

• All students should receive at least two meetings per semester in each of Semesters 1 and 2, with at least one of these being on an individual basis, the other being individual or group-based.
• Permitting one supervision meeting per semester to be held over Zoom (the other being face-to-face).
• Supervision meetings should be recorded in e:Vision for all students and within two weeks of the scheduled meeting.

Longer term, we are looking at the potential to use Check-In for supervisor meetings in order to streamline our processes.

All departments are using Check-In with the exception of the following where separate, agreed arrangements are in place:

• CPD students
• Hull York Medical School
• Lifelong Learning
• PGR students
• York Online

The International Pathway College will start using Check-In in phase 2 of the project.

We aren't able to stop students who are attending a session from sharing the code with students who are not there in person.

When deciding on the approach to take with codes, we considered setting up dynamic QR codes that would change every 10 seconds (thereby reducing the potential for sharing) or limiting access to the portal to the campus IP address only; however neither of these options were practicable. In other universities who use the same system, the problem of students sharing codes has not been as widespread an issue as might have been expected. This is consistent with feedback from departments in York that operate local systems. 

We have ensured that our student comms explain the important welfare and wellbeing reasons underpinning Check-In and why it is an essential tool for staff to support students who may be struggling. 

Lecture capture is not integrated in this phase as we are only looking at attendance at physical events as a way of knowing whether students are engaging with on-campus events. If an event is watched live, then students can check-in in the same way as if they are in person (the Check-In code will only be live for the length of the session). Having recapture as an engagement point is something that we will be looking at in phase 2.

Check-In has a lot of functionality that we will be exploring over the coming year once the basic system is in place, with the ultimate goal of having everything related to absence in one place (for example leave of absence and self-certification) but for now please follow existing processes for logging and managing absence. There is an option to manually add absence periods in Check-In if you think this would be of use.

The new Check-In system will be used to record and monitor engagement rather than any functionality available through the VLE. An integration with the VLE is something the project would like to explore in phase 2.

Teaching staff will be sent an email reminder at 3pm the day before their teaching event and at that point you can login to Check-In to generate a code. We don’t recommend generating codes any earlier than the day before the event, in case there are changes to the timetable which may then make the previously-generated code invalid. This is new guidance due to the way timetables are updated at the start of term, and we hope to move back soon to allowing codes to be generated seven days before a teaching event.

Allocations and changes to timetables can take the Timetabling Team up to a week to process as they involve manual work by the team. Please allow the team a week to make any changes that you have requested before sending them a chaser.

Once changes have been made, they will be reflected in the Check-In system after a short delay: every 15 minutes between the hours of 7am and 11pm, the system will search for any changes in that day's timetables and update Check-In shortly after. Timetables for the next 14 days are automatically uploaded every morning at 6am.

You will be able to see your timetable in Check-In two weeks in advance.

If a student struggles to check into the system, a member of the teaching staff can manually check them into the event.

If the student has further issues, in the first instance they can speak with a member of professional services staff in their Department.

At this time, departments can choose to send follow-up emails from Check-In, either the template or slightly modified version. Departments can choose to send their own.

It is important that these emails are engaging and focus on the wellbeing of the student. Where possible, it is advised to keep these emails to a minimum. 

The system has an automatic feed from the timetabling system, so any staff member with a centrally timetabled activity in that academic year will get an account, even if they start mid-year.

Yes, it is possible for GTAs to present a code:

• They can be given a code that was generated by another member of staff before the session
• Alternatively, they can log in to the system and search for the assigned staff member’s timetable to generate the code themselves

In order for users with multiple roles (staff and student) to generate and enter codes, there is a different website link for the two versions of the system and logins will be granted appropriately.

Yes, as long as the colleague stepping in to cover has access to the Check-In system, then they will be able to generate a code for that session. 

There is potential functionality in Check-In to create your own events and then generate codes; however this will not be rolled out in the initial launch phase and is something that will be looked at as part of phase 2 of the project.

The codes are valid for the duration of the teaching session.

Check to see if there have been any timetable changes since you generated the code. If there have been any changes, your original Check-In code will not work. Unfortunately, generating a new code for that session doesn't resolve this issue either.

We are currently working on resolving this issue. In the meantime, to ensure codes are valid, please generate them as close to the start of the session as possible due to the amount of timetable changes currently happening.

If in doubt, there is an option to revoke the code and then you can generate a new one.

If you want to edit the register list before the event starts, you will need to click the ‘Start’ button first in order to make any changes to the list. It doesn’t matter if you start this list early. As soon as at least one student has checked in to the event, it will automatically be ‘Started’ and remain this way so attendance can be updated after the event has finished without needing to click the ‘Start’ button.

Find out more about the register list.

If more than one staff member is named against an event, they will all receive an email inviting them to generate a Check-In code. If they go in and see the code is already there, then they will know a colleague has already generated the code for the session. It’s not possible for the system to allow multiple people to generate different codes at the same event, you will first have to revoke the code in order to change it.

Two people can’t both generate a code at the same time for the exact same session; an error message would automatically come up for one of the people trying. If a code has already been created, when you go to generate a code you will see the code which will need revoking first before a new one is shown.

Only one Check-In code needs to be generated for sessions which are taking place in the same room at the same time. Therefore, students on different modules will enter in the same code at these events. From a staff perspective, multiple events will appear on your timetable but when generating a code it will automatically link the same code to all ‘co-located’ activities. Do be aware though, students will appear on separate register lists if you wish to manually enter engagement at these events.

Learn more about co-located events.

Check-In has an built-in feature that means if an event is happening at the same time in the same room, then the code generated is the same for all of those 'co-located ' events. However, if the same event is happening but in different rooms, then the codes will be different for each of the rooms. We are working with the supplier to change this so that only one code is needed; however this requires some more design and development work and we’re not quite there yet. 

Due to the confusion it may cause for students, we recommend taking a paper register for these classes and inputting attendance manually into Check-In after the event (you may want to to speak to your department about whether to do this and who's responsibility this additional task will be). 

Providing the lab session is centrally timetabled, it will feed through to the Check-In system. If the lab is directed by a member of staff, a Check-In code can be generated and the session can be treated in the same way as lectures or seminars. Check-In codes can only be used once in a session though, so this would only give a record of whether a student was present or absent from the entire session. Check-In codes can also be generated by Graduate Teaching Assistants to be shared in the session by searching for the event lead’s timetable in Check-In.

We know some lab sessions have specific requirements, for example:

• Some labs require students to be able to check out as well as check in for the session; 
• Labs can run for longer periods of time with students coming and going (checking in and out) as required;
• Some labs have an academic scheduled in the timetable, but they won’t always attend. This means it would be challenging for a Check-In code to be generated and shared with students.

As Check-In relies on staff to generate and share a Check-In code that can only be used once for a session, we understand Check-In currently doesn’t meet these requirements. However, it is still important to record lab attendance in Check-In for welfare and wellbeing reporting purposes, even if Check-In will not include additional attendance requirements (such as the time a student left the lab).

It is therefore recommended that departments continue this academic year with their current processes for recording lab attendance, such as a student signing in and out on paper. After the lab session, a member of staff (for example an administrator or Graduate Teaching Assistant) should update Check-In with student attendance by manually recording students as present or absent. Departments should decide how best to manage this process locally.

If there are technical issues, please make sure that the students at your session leave their details so that they can be added into Check-In afterwards, either by yourself or a member of the departmental admin team. 

If, for any reason, it is not possible to do this, students will not be penalised for not registering their engagement if no Check-In code could be used (these types of sessions are shown in a separate report). If some students were able to register their engagement before Check-In access failed, you should email check-in-support@york.ac.uk so that this data can be adjusted in the system.

The Head of Networks at the University is keen to gather information about wifi dark spots around campus; please directly email mark.franklin@york.ac.uk to report specific rooms with wifi issues.

We’re working with the system provider, SIMAC, to improve this. In the meantime, event details can be checked individually by clicking on the event and looking at the pop-up box, or by using the list view for the timetable; this will show each event as an easily readable line in list format.

Check-In only has to be used for physical on-campus teaching events, and has been developed so that it excludes online only events from your timetable view in Check-In. However this may not be 100% accurate for all of these events, as it depends on timetabling data. If a session you run is for online only attendance but it appears in Check-In, you don’t need to generate a code for it. This won’t affect student engagement data and will be flagged in a separate report for us to monitor.

Check-In will only show events in the timetable if they have a member of staff, a location, a time and one or more students attached to it. If the students are missing from an activity import, the event will not be shown on a staff member timetable. MyTimetable should always be considered to be the main source of truth for timetabled events.

There are a number of optional activities (eg English and Maths skills, Year in Industry, or drop-in sessions) that are timetabled centrally and show up in Check-In but are out of scope of the project. This is because these activities are not currently included within the Student Academic Engagement and Wellbeing Policy which focuses primarily on lectures, tutorials, seminars, lab sessions and Independent Study Module project meetings. The project team will be refining the Check-In data feed so that any event that is not included in the policy will stop showing up in Check-In to avoid confusion.

Teaching staff will be able to generate a code 24 hours ahead of their teaching session; this code can then be brought along to the session for writing on a whiteboard or shouting out at the start of the session without the need for the member of staff to access a computer. Students will then be able to input the code given to them on their personal device.  

Yes, you can manually add students. Find the event in the timetable, go to the register list, go to ‘add student’ and add them in manually. This can either be done at the session or retrospectively afterwards. Students can also be removed from an event in Check-In if they end up attending a different session. If you are making changes retrospectively, this may affect any reports that are generated before this retrospective data is added.

We are using Check-In to look at overall student engagement with academic programmes rather than focussing on individual sessions where students may have very legitimate reasons not to be present. Check-In should therefore be used as part of providing an overall picture of engagement. Over the first year of implementation we want to make sure that the data recorded is accurate so we would advise a level of caution when using it as part of student references.

We strongly encourage all teaching staff to actively engage with Check-In as it is a key part of the University’s commitment to supporting student welfare and wellbeing. Without a better understanding of student engagement, we will not be able to provide the additional help and support that some of our students may need. Students will also start expecting the codes to be available at their sessions. 

If you have any questions or concerns about using Check-In, please discuss these with your line manager and/or Head of Department; they will have access to information about the take-up of Check-In across departments and may follow up where codes are not being generated.

As teaching staff, you will have administrator access to the system and will be able to override and update the actual attendance for the session if you wish. We don’t expect teaching staff to be responsible for ensuring students aren’t sharing the codes. Students are informed not to do this and by checking in others on their behalf, they are potentially preventing others from receiving welfare and wellbeing support.

We are currently working with SSMs and departmental admin teams on reporting functionality and processes for Check-In. 

Viewing event reports

The system will automatically mark students as 'missed' for an event at approximately 9pm that evening; this means that the event will stay orange on the Check-In system until that point but will then turn green overnight. It is important to note that when pulling data reports, the current day is always pending so you won’t be able to report on an event until the day after it has taken place.

Viewing engagement information

Check-In is built on static flows at weeks 5 and 10. At these two points, the system generates a list of students who have not met the threshold engagement criteria. The reporting suite is synced live to view the data whenever you want to so there is no delay in reporting. For example, you could pull a report at the start and end of a session to see the different times people came in if you wanted to.

What reports are available?

At the moment there is a 'flow' (snapshot) report after each teaching block (5 weeks and 6 weeks) to identify any students that fall below the minimum threshold. We are exploring whether the flow can be produced weekly for those departments wishing to go above and beyond the minimum teaching block/week 5 threshold and will give more information in the coming weeks if this is possible.

Please contact your SSM or departmental admin team if you have any questions about reporting.

There will be a reporting suite in the system as well as a full dataset copy added to a new reporting database. Access to this data will be restricted but the project implementation team can discuss your individual needs. We anticipate that phase 2 of the project will provide better data feeds.

Data access and collection is agreed through the Check-In Data Protection Impact Assessment (DPIA) to meet our record retention schedule and will not be kept for longer than is necessary or viewed by those who do not need it as per GDPR regulations. Access to the central database will be locked down and managed by the operational owner. Reporting in Check-In is only available for the current academic year and will be available to all teaching staff, and a small number of professional services staff who require it to provide welfare and wellbeing support.

A computing risk assessment has been approved to allow processing by our third party supplier. The data will remain within the EU at their data centre location. A Data Protection Impact Assessment (DPIA) is in place and will be signed off by the University’s Data Protection Officer before we go live.

In order to ensure that students are benefiting from their studies, and to monitor students’ academic progress and wellbeing, the University monitors student engagement on their programmes in order to quickly identify those who may be experiencing difficulties and/or at risk of disengaging from their programme. In order to carry this out we have a lawful basis for processing the data as agreed in the DPIA.

Attendance at timetabled teaching sessions is an essential part of the student learning experience on all courses at the University; much of the curriculum content of courses is conveyed through timetabled teaching sessions. Such sessions also give students opportunities to interact with academic staff and other students about course-related themes and issues. Attendance is similarly central to students’ success where courses have practical or placement elements. We therefore strongly encourage students to make every effort to attend all timetabled teaching sessions (including practical, workshop and laboratory classes) and, where applicable, Placements.

Students will be expected to engage with the process of registering their attendance by submitting a six digit code at each timetabled teaching session. While we encourage students to engage with this process, they will have the ability to make a choice on whether to share this data with the University or not.

Check-In is not designed to be a punitive system. The purpose of Check-In is to support student welfare and wellbeing by being aware at a much earlier stage where students may be experiencing difficulties and not able to engage with their programmes.