Skip to main content

This site is used internally in the Department for Education.

Service rules

School admins

This document currently covers the service rules for school admins.

School admins are also known as:

  • school users
  • school induction tutors (SITs)
  • school induction coordinators

Request access to the Manage ECTs service via school GIAS email

Context: For schools to use the Manage ECTs service, they first need to register. This functionality is used both for schools who are using the service for the first time as well as schools that can no longer access the service via their existing SIT email (e.g. SIT has left).


To register, the user must identify the school in our GIAS register subset using local authority (LA) and school name. The school must be open and either an eligible establishment type and/or in England. If school can't be found in the GIAS list, they can't request a link to access the service.

πŸ“Š The GIAS register is used in order to check that the school is real. This is the most up to date list of schools available, with most of the details we need to check schools' eligibility to have ECTs serve induction.

πŸ“œ School eligibility requirements for accessing the service come from the statutory guidance which details the schools where ECTs can serve induction.


School URN and address are shown for the user to confirm the correct school.

πŸ“Š These are publicly available, unique school details to help the user confirm we have identified the correct school.


GIAS email is shown in redacted form, including the first and last letter of the username and the full domain name (i.e. ).

πŸ™‹ Redacted email is shown to help schools identify where the GIAS email has been sent.

πŸ”’ The email is redacted because GIAS email is not publicly available information.


GIAS email can't be changed within the service - if the GIAS email is incorrect/out of date, school needs to update it using DfE sign in.

πŸ“Š GIAS is the source of truth for the school email and can be updated via DfE Sign-in. An email is sent to the school GIAS email on confirmation.

πŸ’» This is to confirm that the person trying to access the service legitimately works at the selected school if they can (indirectly) access their school's GIAS email.

πŸ“Š GIAS email is the most direct and up to date contact we have for schools (until SIT details are provided).


Anyone can trigger the link being sent to a school's GIAS email and there is no limit on the number of times access can be requested.

πŸ’» We don't know who specifically will need to access the service before we are told by the school and the current process means we don't / can't limit access for requesting the link to particular people. There is no specific need to limit the number of times access can be requested.


The link can be requested regardless of whether the school already has a SIT nominated or not.

πŸ™‹ This is to account for schools where the existing SIT account can no longer be accessed (see design history).


Nominate a school induction tutor (SIT)

Context: Schools are asked to nominate an individual as the 'induction tutor' who will oversee the induction and training process to ensure that ECTs and their mentors are effectively supported and guided through induction. Part of this role is to use the manage ECTs service to give details of their school's mentors, ECTs and training option to DfE to enable delivery and funding for ECTP training.


Schools that say they are not expecting ECTs for the upcoming/current (depending on when they access the service) academic year are not asked to nominate a SIT or use the service to report any further information.

πŸ’» The data collected in the Manage ECTs service is not applicable to schools that aren't expecting ECTs, so we don't need the school to nominate a SIT user or sign into the service.


Schools that say they are expecting ECTs or are not sure yet must nominate a SIT.

πŸ“œ This comes from the requirements in the DfE guidance that it is a SIT responsibility to use the service. Only one SIT can be nominated per school.

πŸ’» UI for multiple user access is supported but not built. There is an assumption that only one person at the school will need to use the service.


Name and email address are provided to nominate the SIT.

πŸ’» The email allows the nominated SIT to sign into the service. We also use their name and email as the contact for DfE comms.


There is a uniqueness validation on email address across all profiles (SITs, ECTs and mentors). However, if both name and email address match an existing record, this person can be registered as the SIT for multiple schools.

πŸ’» The uniqueness validation is to avoid the same email address being used for different people. The combined name and email match is to account for SIT who work across multiple schools (e.g. in a MAT).


An email is sent to the nominated SIT on confirmation.

πŸ’» The user nominating the SIT may not be the SIT themselves, so the email notifies the nominated SIT and provides instructions for signing into the service.


Nominated SIT will be the email used for all further comms.

πŸ’» Once nominated, the SIT becomes DfE's most direct point of contact with the school and is responsible for reporting early career teacher training details.

Log in with an email address once nominated as SIT

Context: Once nominated, the SIT becomes the school's user for the Manage ECTs service and must log in to use the service and report early career teacher training details for their school.

If user enters a registered email address on the sign in page, they are sent a magic sign in link via email which they can use to directly log into the service.

πŸ’» Magic sign in link approach was deemed to be the best approach at the time of original build.

If the email address is not registered, the unregistered email is sent an email to explain next steps.

πŸ™‹ This email was created to reduce the number of support requests from people who couldn't remember if they had used the service before or not, and people who couldn't remember which email was registered (see design history). User must agree to privacy policy on first sign in.

πŸ”’ It is a GDPR requirement to inform users of how DfE will use their data.

Manage multiple schools with one email address

Context: Some SITs may work across multiple schools (e.g. in a Multi Academy Trust or MAT), and they can manage their multiple schools using the same email login for the service.


Multiple schools can nominate the same induction tutor if both name and email address match an existing record.

πŸ’» This is to account for SITs that may work across multiple schools (e.g. in a MAT).


When signed into the service, the user can select between which of their schools they would like to manage. They can only manage a school one at a time.

πŸ’» The service was not built with this use case in mind.


Change the SIT

Context: Only one SIT user per school can use the service at a time, and this person can be changed and replaced by someone else at the school if needed (e.g. if they leave the school, change role).

User can change the nominated SIT and replace themselves with a different person by changing both nominated SIT name and email.

πŸ’» This is to allow the SIT to be updated when there is a change in role or the existing SIT leaves.

User can change their own registered email by entering the same name and changing the email only.

There isn't an explicit journey built to change details of the existing SIT (existing functionality is used as a hack). There is a uniqueness validation on email address across all SITs, ECTs and mentors. However, if both name and email address match an existing SIT record, this person can be registered as the SIT for multiple schools.

πŸ’» The uniqueness validation is to avoid the same email address being used for different people. The combined name and email match is to account for SITs who work across multiple schools (e.g. in a MAT).

The user cannot change their own name whilst keeping their existing email.

When a user changes the SIT details, they immediately lose access to the SIT dashboard.

πŸ’» UI for multiple user access is supported but not built. There is an assumption that only one person at the school will need to use the service.

An email is sent to the new nominated SIT on confirmation.

πŸ’» This email is to notify the new nominated SIT and provides instructions for signing into the service.

New nominated SIT will be the email used for all further comms.

πŸ’» Once nominated, the SIT becomes DfE's most direct point of contact with the school and is responsible for reporting ECTP training details.

Select and change the school induction programme

Context: Each year, the SIT must report / confirm their 'default' programme choice for the academic year.

If a school is expecting ECTs, they must report which training programme their ECTs will be completing.

πŸ“š DfE needs to know which participants have chosen provider-led training, so that we can share the relevant school and participant details with providers and so that we can calculate funding for schools and providers. DfE also needs to know which participants have chosen school-led training, so that we can signpost to materials and so that we can calculate funding for schools.


Schools will only be able to choose the programme options they are eligible for. If a school is eligible for DfE funded training, they can choose between β€˜Provider-led or government-funded training’ and β€˜school-led training’ If a school is not eligible for DfE funded training, they can only select school-led training (or CIP or DIY?).

πŸ“œ Only state-funded schools, colleges, sixth forms, children's centres and nurseries, maintained and non-maintained special schools, and independent schools that receive Section 41 funding are eligible for DfE funded training (see DfE guidance). Other schools can access the service for CIP materials, or self-funded FIP.


🚧 Schools must set a β€˜default’ programme choice. TBC how the default is used when new ECTs & mentors are added.

πŸ™‹ This is to reflect how things work on the ground. The majority of schools with multiple ECTs will be doing the same programme, so the β€˜default’ can help speed up the journey for adding new participants.


If a school chose FIP and had a partnership reported in the previous academic year, they should be able to rollover their previous programme and partnership choice. If a school’s previous LP/DP pairing is no longer available or no partnership was previously reported, there should be no option to rollover.

πŸ“œ The policy intent is for schools to continue with the FIP programme and the same LP/DP where possible.

πŸ“š Some LP/DP contracts change year to year which means schools may not be able to continue working with the same pairing for the following year (see design history).


🚧 LP is emailed if school is not able to automatically rollover their previous partnership due to a change in LP/DP pairing.

πŸ’» If school reports that they're doing FIP again, the service treats it as a rejection of the partnership and triggers an email to the LP. This flags to the LP that if they are still working with the school with a new DP then they need to let us know which DP.


🚧 If user chose CIP, DIY, or didn't have a programme choice in the previous academic year, they must select their programme choice for the new academic year.

πŸ™‹ The rollover mechanism was built for FIP as this was relevant to the majority of schools and helped speed up the registration journey for these schools. It was not an active choice to not let CIP and DIY schools rollover.


🚧 Once user has submitted their programme choice for an academic year, they must contact support to change the choice.

πŸ’» This was not a deliberate rule, there is no strong policy reason. Note, LP can override the programme choice by reporting a partnership. As long as the school has a cohort set up for that year, this sets the programme choice to FIP for that school.


🚧 Once default programme choice is selected for an academic year, new ECTs and mentors in that year will be set to use this programme when registered.

πŸ™‹ This is to reflect how things work on the ground. The majority of schools with multiple ECTs will be doing the same programme.


Appoint and change Appropriate Body for a cohort or individual ECT

Context: Schools must appoint an appropriate body (outside of the Manage ECTs service) for their ECTs. We ask SITs to report their AB choice(s) to DfE via the Manage ECTs service. It is not a statutory need to report within the service -- in fact it needs to be reported outside of the service. We use the info to play the details back to the ABs -- to cross reference check where schools have registered ECTs for training without registering for induction. On their records they can also see the other way round -- might mean they've not filled in the AB or not registered the ECT at all.


SITs must report who they have appointed as their AB for their ECTs from a set list of ABs, which is updated each year and provided by the policy team. Currently:

All schools can appoint a teaching school hub from the hardcoded list in the service.

Independent schools only can also appoint Independent Schools Teacher Induction Panel (ISTIP).

British schools overseas only can also appoint Educational Success Partners (ESP).

πŸ“œ Schools that will deliver any form of ECF-based training must appoint an AB for each of their ECTs. Schools can choose whether to appoint one appropriate body for all of their ECTs, or different ones.

πŸ“œ DfE guidance sets out the organisations that can or cannot act as an AB. From September 2024, Teaching school hubs will become the main appropriate body providers -- details can be found on gov.uk. We get the list for the service from policy -- there are 3 lists on gov.uk so policy give us the exact names.

πŸ“Š Presenting only the eligible options to different types of schools in the service aims to improve data accuracy (design history).

πŸ“š Reporting the AB to DfE enables ABs to cross check that ECTs have been registered for both induction and training.


View and challenge partnerships for an academic year

Context: FIP schools choose a lead provider and delivery partner to deliver training for their ECTs. Once this agreement between the school and LP has been made outside of the Manage ECTs service, LPs report this partnership via the API.


The nominated SIT email is used to log into the service. When a SIT enters the registered email into the service login page, an email is sent to their email with a magic sign in link to sign into the service.

πŸ’» Magic link approach was decided to be the best sign in option at the time.


When LP has reported a partnership with a school, LP and DP name are shown in the SIT dashboard.

πŸ“š As schools do not report partnerships themselves, showing the partnership as reported by the LP allows schools to see if the details are as expected.

πŸ’» The provider reporting the partnership journey (rather than schools) was easier to build originally.


Partnership can only be challenged during the first two weeks after it has been reported (if at another time of year), or in the first 3 months of the academic year. This voids the partnership.

πŸ’» This is to allow schools to correct provider errors. For example in some cases a provider can jump the gun and report a partnership when the school is actually speaking to multiple providers about forming a partnership still.

πŸ’» The challenge window is limited because schools can cause problems and impact declarations when they challenge a partnership.


There can only be one 'default' partnership for an academic year. LP can't claim a school if they already have a partnership -- school needs to challenge the existing partnership first.

πŸ“š Original assumption that everyone at a school would be doing the same thing -- exceptions added later (smaller numbers). Choices for each year are now less relevant -- we know schools' preference is to shift all participants, including those mid training, when a LP/DP pairing changes.


After, the lead provider and delivery partner cannot be changed without contacting support.

πŸ’» The challenge window is limited because schools can cause problems and impact declarations when they challenge a partnership.


Add an ECT

Context: SITs are asked to register any new ECTs each year and provide details to enable DfE to check their eligibility for funding and pass details of ECTs to LPs to facilitate access to training.


School must enter an ECT's TRN and DoB, so we can match them in DQT: - TRN must be a 7 digit number - ECT must be between 18 and 100 years old

Note, in the future TRS API, we might be able to use name and date of birth.

πŸ“œ We need to match ECTs with their DQT record to ensure only real ECTs are registered for training as part of statutory induction, and so DfE to check eligibility for funding. πŸ™‹ Schools enter these details on behalf of ECTs as this caused confusion and delays when previously entered by the ECTs themselves (see design history).


Identify the teacher in TRA using their TRN and DOB and confirm the match by comparing their name. If there are no matches try re-matching with the inclusion of National Insurance Number.

πŸ“š This is to enable DfE to check eligibility for funding (see section below).


🚧 If we can identify the participant in TRA, we check first name matches. If name doesn't match, we ask if they are known by a different name until there is a match.

πŸ“œ This is to enable real ECTs to register for training as part of statutory induction.

πŸ“š This is to enable DfE to check eligibility for funding (see section below).


If a teacher can't be found in the DQT, they cannot be added as an ECT.

πŸ’» This prevents ECTs being added with incorrect details that may never be validated. This was previously allowed and required lots of manual checks.


🚧 Name and email address is also provided when an ECT is added. Note, we may decide to pull these details from DQT rather than asking schools for them.

There is a uniqueness validation on email addresses -- identities have a unique constraint and users have a unique constraint.

πŸ™‹ This is to pass the details onto the LPs for onboarding to their learning platform & invitations to training events. We also pass this over for external evaluations (this is in the privacy policy).

πŸ’» The uniqueness validation is to avoid the same email address being used for different people.

πŸ”’ We are required to send a privacy policy to registered ECTs.

πŸ“œ We also pass these details over for external evaluations (this is in the privacy policy).


Once we have successfully matched the participant in DQT, the ECT must pass the following checks to be added in the service:

The teacher must not have an overall induction completion date. The teacher is not eligible for ECTP training if they have already completed induction.

πŸ“œ Teachers can only complete ECTP training once.

The teacher is not eligible for ECTP training if they have an induction status of β€˜exempt’ from induction.

πŸ“œ Teachers may be exempt from completing ECTP training.

The teacher must not be currently ECTP mentor training. The teacher cannot receive funding for both ECT training and mentor training at the same time.

πŸ“œ DfE only fund one set of training at a time, this was agreed at ECF working group.


When ECT details are reported, an email is sent to the participant informing them they've been registered and to provide a privacy policy.

πŸ”’ This is GDPR requirement.


When the teacher is added, we check the following details to confirm their eligibility for ECTP training:

Prohibitions, sanctions or restrictions on their DQT teacher record: If an ECT does have an active flag, they can be added but won't be eligible to start training yet until they have been reviewed and approved by the policy team.

πŸ“œ Teachers who are barred from teaching are not eligible for ECTP training.

QTS recorded in DQT: ECTs must have QTS to be eligible for training. If an ECT doesn’t yet have QTS, they can be added but won't be eligible to start training yet.

πŸ“š QTS is used to confirm the ECT's eligibility for funding.

πŸ™‹ School may want to register their incoming ECTs before they have finished their ITT.

Induction start date recorded in DQT: ECTs must have an induction start date recorded by their AB to be eligible for training. If an ECT doesn’t yet have an induction start date, they can be added but won't be eligible to start training yet.

πŸ“š The induction start date is used to confirm the correct cohort allocation.

If an ECT passes the above checks, they become eligible to start training. Note, the above details can change, so should be re-checked.


Transfer in an ECT

Context: Some ECTs transfer schools during induction, which may also involve changing their training option/LP/AB. We ask SITs to reflect these changes in the Manage ECTs service to ensure the correct payments are made.


Schools must have selected a default programme choice for an academic year to be able to transfer in an ECT for that year.

πŸ™‹ Most schools choose the same programme for all their ECTs in a particular year (with exceptions for things like transfers), so we ask schools to choose a 'default' which is used for any new ECTs rather than asking the user to select the same thing for each of their ECTs individually.


If ECT identified in TRA is already registered at another school in the service during ECT registration, user asked to confirm that they are transferring the ECT into their school.

πŸ’» This allows us to retain the ECT's participant profile so we know what training they have completed, which is captured in the history of declarations received (see design history).

πŸ“š This ensures we only pay providers what they are owed for the training they delivered to the participant based on the payment milestones.


Specify date ECT will be transferring in, which can be in the past or future.

πŸ’» This is used to trigger a change in status for the ECT in the SIT dashboard. The date will also trigger the ECT to show as no longer training at the old school.


User can choose to continue with ECT's LP/DP from previous school or switch to new LP/DP (either the school's default LP or other).

πŸ“œ There is a policy preference / assumption that it's in ECTs best interest to continue with the same provider. This was previously a DfE recommendation, but now watered down and schools tend to have a stronger preference to have all their participants with the same provider, including transfers.


User can change ECT's email address as part of transfer in. In this case both email addresses are associated with the participant.

πŸ™‹ Participants usually get a new email address when they move to a new school. We need up to date emails because we pass this over for external evaluations (this is in the privacy policy) and give emails to LPs.


If a teacher is registered as a mentor in the service, they cannot be added as an ECT.

πŸ“œ DfE only fund one set of training at a time - this was agreed at ECF working group.


An email is sent to the participant informing them they've been registered.

πŸ”’ This is to provide participants with the privacy policy, and set expectations about hearing from the provider. LPs is emailed on reporting of transfer.

πŸ™‹ Before API v3, it was more difficult to see the details around transfers, so provider emails were sent to notify them of transfers. These may no longer be needed now.


On the joining date, ECT is shown as 'left' at their previous school.

πŸ’» We assume that the ECT is no longer working at their previous school if a new school has claimed them. We don't support ECTs working across multiple schools.


On the joining date, ECT is unpaired from any mentor they were paired with at previous school.

πŸ’» We assume that the ECT will no longer be mentored by the mentor at their previous school, so remove the pairing.


Change an existing ECT's details (from ECT profile)

Context: SITs are able to change certain details of registered ECTs to account for errors and genuine changes in details.


User can change ECT name.

SIT can change name if it's due to the ECT having changed their name (marriage, divorce etc) or their name was entered incorrectly. SIT blocked from changing name if they say the ECT shouldn't have been registered or they want to replace them with a different person.

ECT must not have completed induction and must not have left the school for the SIT to be able to change name. There is an option to contact support if the ECT has completed or left.

We allow changing the whole name.

πŸ™‹ ECT may have a name change or have an error in the entered name.

πŸ’» We ask why an ECT's name needs changing because SITs were previously using this functionality as a 'hack' for replacing an existing ECT with a different person in the service.

πŸ’» Allowing changing whole name creates a risk that users could still overwrite a record with a different person as we don't revalidate.


SIT can change ECT email.

ECT must not have completed induction and must not have left the school for the SIT to be able to change email. There is an option to contact support if the ECT has completed or left.

There is a uniqueness validation on email addresses.

πŸ“š ECT may have a change to their email address -- we need up to date emails because we pass this over for external evaluations (this is in the privacy policy) and give emails to LPs.

πŸ™‹ Some people might register with personal emails first because they don't have a school email yet, so need to change it later.

πŸ’» The uniqueness validation is to avoid the same email address being used for different people.


User can change AB.

ECT must not have completed induction and must not have left the school for the SIT to be able to change AB.

SITs can add/change the AB for an individual ECT -- the AB for individual can be the same or different to the default for their cohort.

All schools can appoint a teaching school hub from the hardcoded list in the service

Independent schools only can also appoint ISTIP

British schools overseas only can also appoint ESP

πŸ™‹ This is to let users correct details where they may have initially entered the wrong one / struggled with the journey.

πŸ“œ Schools that will deliver any form of ECF-based training (FIP, CIP or DIY) must appoint an AB for each of their ECTs. Schools can choose whether to appoint one appropriate body for all of their ECTs, or different ones.

πŸ“œ DfE guidance sets out the organisations that can or cannot act as an AB. We get the list for the service from policy -- there are 3 lists on gov.uk so policy give us the exact names.

πŸ“š Schools should report to DfE who the AB is for each of their ECTs from a defined list of organisations that can act as an AB for each cohort.

πŸ“Š Presenting only the eligible options to different types of schools in the service aims to improve data accuracy (design history).


User cannot change TRN, DoB, or LP without contacting support.

πŸ’» TRN and DOB are used to validate the participant, so the participant needs to be re-validated when changing these details. A way to re-validate participants automatically in the service hasn't been built so is done manually via support.

View ECT eligibility / training status

Context: Registered ECTs are shown to SITs in the Manage ECTs service to allow them to view details and manage any changes.


SITs can view and filter ECTs who are currently training, completed induction and no longer training.

πŸ™‹ This is to allow users to easily find the ECTs their looking for (see design history)


SITs can view ECT induction start date. We do not show ECT cohorts.

πŸ™‹ This is to allow users to easily see which stage an ECT is at without showing cohorts as this was found to be confusing (see design history).


Add a mentor

Context: All ECTs must be assigned a mentor as part of their statutory induction. Mentors must be registered and assigned in the Manage ECTs service for schools to get funding for mentor time off timetable and to provide mentors access to their ECT's materials. FIP / provider-led mentors are also entitled to mentor training and associated funding for schools and providers.


Mentor must have a TRN to be registered. If mentor doesn't already have a TRN, they can request one outside the service: https://www.gov.uk/guidance/teacher-reference-number-trn

πŸ“š This is to enable DfE to check against TRA records that the mentor does not have any prohibitions, sanctions or restrictions on their record, and to check eligibility for funding (see section below).


School must enter the mentor's TRN and DoB, so we can match them in DQT: - TRN must be a 7 digit number - Mentor must be between 18 and 100 years old

Note, in the future TRS API, we might be able to use name and date of birth.

πŸ“œ We need to match mentors with their DQT record to ensure only real teachers are registered for mentoring and/or mentor training, and so DfE to check eligibility for funding. πŸ™‹ Schools enter these details on behalf of ECTs as this caused confusion and delays when previously entered by the ECTs themselves (see design history).


Identify the teacher in TRA using their TRN and DOB and confirm the match by comparing their name. If there are no matches try re-matching with the inclusion of National Insurance Number.

πŸ“š This is to enable DfE to check against TRA records that the mentor does not have any prohibitions, sanctions or restrictions on their record, and to check eligibility for funding (see section below).


If a teacher can't be found in the DQT, they cannot be added as a mentor.

πŸ“š This is because we can't check against TRA records that the mentor does not have any prohibitions, sanctions or restrictions on their record, and we can't check eligibility for funding (see section below).


🚧 If we can identify the participant in TRA, we check first name matches. If name doesn't match, we ask if they are known by a different name until there is a match.

πŸ“š This is to enable DfE to check against TRA records that the mentor does not have any prohibitions, sanctions or restrictions on their record, and to check eligibility for funding (see section below).


🚧 Name and email address is also provided when an ECT is added. Note, we may decide to pull these details from DQT rather than asking schools for them.

There is uniqueness validation on email addresses.

πŸ™‹ For FIP mentors, this is so we can pass the details onto the LPs for onboarding to their learning platform and invitations to training events.

πŸ”’ We are required to send a privacy policy to registered mentors.

πŸ“œ We also pass these details over for external evaluations (this is in the privacy policy).

πŸ’» The uniqueness validation is to avoid the same email address being used for different people.


🚧 A SIT can add themselves as a mentor using the same journey.

πŸ“œ DfE guidance encourages schools to separate the roles of SIT and mentor, but they can still add themselves if needed (see design history).


When mentor details are reported, an email is sent to the participant on confirmation informing them they've been registered. This isn't sent if the mentor is also a registered SIT.

πŸ”’ This is to provide participants with the privacy policy, and set expectations about hearing from the provider.


When the teacher is added, we check the following details to confirm their eligibility for mentoring:

Prohibitions, sanctions or restrictions on their DQT teacher record: If an ECT does have an active flag, they can be added but won't be eligible to start training yet until they have been reviewed and approved by the policy team.

πŸ“œ Teachers who are barred from teaching are not eligible to mentor ECTs.


If a teacher is eligible for mentoring, we also check the following details to confirm their eligibility for funded mentor training:

The teacher must not have already completed mentor training: If a teacher completed mentor training as part of the Earyl Roll Out, or if they have received a β€˜Completed’ declaration, they are not eligible for further funded training.

πŸ“œ Mentors can only complete funded mentor training once.

The teacher must not have started mentor training and had 3 years elapsed without completing the training.

πŸ“œ Mentors are no longer eligible for further funded training if they started but haven’t completed their training within 3 years. This was agreed at the ECF Working Group.

The mentor must be appointed for an ECT who is completing provider-led ECTP training.

πŸ“œ Mentors must be appointed for an ECT to become eligible to start mentor training. Note, they do not have to start paired with that ECT to be allowed to continue training.

If a mentor passes the above checks, they become eligible to start training. Note, the above details can change, so should be re-checked.

Transfer in a mentor

Context: Some mentors transfer schools each year. We ask SITs to reflect these changes in the Manage ECTs service to ensure the correct payments are made.


If mentor identified in TRA is already registered at another school in the service during mentor registration, user is asked to confirm that they are transferring the mentor into their school.

πŸ’» This allows us to retain the mentor's participant profile so we know what training they have completed, which is captured in the history of declarations received (see design history).

πŸ“š This ensures we only pay providers what they are owed for the training they delivered to the participant based on the payment milestones.


Specify date mentor will be transferring in, which can be in the past or future.

πŸ’» This is used to trigger a change in status for the mentor in the SIT dashboard.


On the leaving date, mentorship links with ECTs at the previous school are removed and the mentor is no longer shown in the pool of mentors.

πŸ’» Unless the mentor is working across multiple schools, they are no longer available to mentor ECTs at the school so are not shown in the dashboard.


SIT is asked if the mentor is mentoring across multiple schools. If yes, they must contact support to complete this. The mentor will show in the list of mentors at both schools.

πŸ’» The service wasn't built to account for this use case.


User can choose to continue with mentor's LP/DP from previous school or switch to new LP/DP (either the school's default LP or other).

πŸ“œ Mentor can choose to continue mentor training without ECT.


User can change mentor's email address as part of transfer in.

πŸ™‹ Participants usually get a new email address when they move to a new school.


An email is sent to the participant informing them they've been registered

πŸ”’ This is to provide participants with the privacy policy, and set expectations about hearing from the provider. It might also email the provider


Change an existing mentor's details (from mentor profile)

Context: SITs are able to change certain details of registered mentors to account for errors and genuine changes in details.


User can change mentor name.

Mentor must not have left the school for the user to be able to change their name. There is an option to contact support if the mentor has left.

SIT can change name if it's due to the mentor having changed their name (marriage, divorce etc) or their name was entered incorrectly. SIT blocked from changing name if they say the mentor shouldn't have been registered or they want to replace them with a different person.

We allow changing the whole name.

πŸ™‹ Mentor may have a name change or have an error in the entered name.

πŸ’» We ask why an ECT's name needs changing because SITs were previously using this functionality as a 'hack' for replacing an existing ECT with a different person in the service.

πŸ’» Allowing changing whole name creates a risk that users could still overwrite a record with a different person as we don't revalidate.


User can change mentor email.

Mentor must not have left the school for the SIT to be able to change email. There is an option to contact support if the mentor has left.

There is a uniqueness validation on email addresses.

πŸ“š Mentor may have a change to their email address -- we need up to date emails because we pass this over for external evaluations (this is in the privacy policy) and give emails to LPs.

πŸ™‹ Some people might register with personal emails first because they don't have a school email yet, so need to change it later.

πŸ’» The uniqueness validation is to avoid the same email address being used for different people.


User cannot change TRN, DoB, or LP without contacting support.

πŸ’» TRN and DOB are used to validate the participant, so the participant needs to be re-validated when changing these details. A way to re-validate participants automatically in the service hasn't been built so is done manually via support.


View mentor mentoring status / training completion status

Context: Registered mentors are shown to SITs in the Manage ECTs service to allow them to view details and manage any changes.


View mentors who are currently mentoring and not mentoring.

πŸ™‹ This is to allow users to more easily find the mentors their looking for.


Context: All ECTs must be assigned a mentor to support them during their induction.


Schools must report one appointed mentor for each of their ECTs. πŸ“œ All ECTs must be assigned a mentor during their induction (see statutory guidance). ECTs must have a dedicated mentor, but there is no limit on having other additional mentors.

πŸ“š DfE commercial decision not to pay for time off timetable for additional mentors.


🚧 User can assign a mentor to an ECT in the ECT registration journey, the mentor registration journey or after an ECT and mentor are registered in the SIT dashboard.

πŸ™‹ The design aims to encourage users to assign a mentor to any ECTs who do not yet have one assigned (see design history).


🚧 Mentor must be registered in the service in the same school as the ECT to be available as a mentor for an ECT. Note, mentors may be in the mentor pool at more than one school.

πŸ’» The service was built on the assumption that a mentor would always be at the same school as their assigned ECT.


There is no limit on the number of ECTs a mentor can be assigned to.

πŸ“œ Whilst there is no specific limit, DfE statutory guidance sets out that mentors should be able to support an ECT, and too many pairings would impact a mentor's capacity to do that.


Assigned mentor for an ECT can be changed to a different registered mentor at any time, but cannot be removed.

πŸ“œ We didn't build this option. Policy that every ECT must have a mentor


User can change mentorship following the same rules above, and:

  • ECT must not have completed induction and must not have left the school for the SIT to be able to change mentor.

  • Mentor must not have left the school for the SIT to be able to change the ECT they are assigned to or add others.


Mentors may or may not be doing mentor training.

πŸ“œ Mentors can choose to take up funded mentor training. Mentors don't need to be in training or have completed training to mentor ECTs.

Report ECT is transferring out

Context: Schools can report that an ECT is leaving their school and transferring to a different school. LPs can view this data via the API but we otherwise do not use this data.


User can report that an ECT is transferring to another school. This is not mandatory.

πŸ™‹ This is to allow SITs to tidy their dashboard and move ECTs who are leaving / have left to a different section ("no longer training") of their school's dashboard if they want to (see design history).


Specify leaving date, which can be in the past or future (no constraints?).

πŸ’» The leaving date triggers the move of that ECT in the SIT dashboard. Email is sent to the ppt on confirmation?


ECT is shown in SIT dashboard as leaving or no longer being trained.

πŸ’» Leaving date not shown in the service once it has been submitted, and can't be changed.


ECT cannot be re-added once they have been reported as leaving / have left.


User cannot report through the service if ECT is leaving for any reason other than transferring to another school.

πŸ’» Moving school was the most common option and other journeys were not built for MVP.

πŸ™‹ We do not yet have a clear understanding of user needs and pain points for this journey (see design history).

Report mentor is transferring out

Context: Schools can report that a mentor is leaving their school and transferring to a different school. LPs can view this data via the API but we otherwise do not use this data.


User can report that a mentor is transferring to another school. This is not mandatory.

πŸ™‹ This is to allow SITs to tidy their dashboard and mark mentors who are leaving / have left if they want to (see design history).


Specify leaving date, which can be in the past or future (no constraints?)

πŸ’» This date becomes the trigger for removing the mentor from the school's mentor pool. [Also removes mentorship links?]


Leaving date not shown in the service once it has been submitted, and can't be changed.


On the leaving date, mentor is removed from the school's mentor pool.

πŸ’» Unless the mentor is working across multiple schools, they are no longer available to mentor ECTs at the school so are not shown in the dashboard.


Mentor cannot be re-added once they have been reported as leaving / have left.


πŸ’» User cannot report through the service if mentor is leaving for any reason other than transferring to another school.

Remove an ECT

Only if the ECT is 'Exempt' from statutory induction? Previously a remove journey for unvalidated ppts?

Contact support or provide feedback on the service

Context: Users may need to access support whilst using the Manage ECTs service. We also want to encourage them to provide service feedback.


User can provide feedback via the feedback form at any point, including before logging into the service.

πŸ’» This follows the GOV.UK Service Manual for measuring user satisfaction.


User can email continuing-professional-development@digital.education.gov.uk

πŸ’» This is to allow users to access support for any issue or query they may have with the service. contact support.


There is no limit on how many times a user can submit feedback or contact support

πŸ’» There is no reason to limit feedback or support per user - users may experience multiple issues that they need support with, and feedback is anonymous so we have no way of limiting feedback per user.


View guidance on how to set up and manage ECF training

Context: Schools can find links from the service to gov.uk guidance for managing ECF training.


User can navigate to guidance on how to set up training for ECTs.

πŸ™‹ This is to provide an overview of what registration involves in the Manage ECTs service.


Key

Emoji Meaning
πŸ™‹ user need
πŸ“œ policy (explicit or intended)
πŸ“š contracts & funding
πŸ’» digital service
πŸ“Š data
πŸ”’ security / GDPR
🚧 ECF 1 - TBC if needed for ECF 2