Reference:

update tables DBC & LocalOffice

Trust, Site table contains `localOffice` name.
`LocalOfficeContact` only contains the localOfficeId, so there's no need to update it.

Profile (User Management):

No need to update anything as it uses the designated body code instead of its name.
LocalOfficeToDbcMapper class. It's not used anywhere. – should we move it or update it?

TCS:

DesignatedBodyMapper class - this is also used for Reval sync
PersonOwner - is populated by Sync service with Programme/Post owner and after that a person elasticsearch sync job needs to be triggered.
Post - owner is from LocalOffice
Programme - owner is from LocalOffice

NDW:

the name changes would impact the fields in NDW tables as below:

Query name	NDW table	Field name
post	vwPost	ManagingDeaneryLETB
assessment	vwAssessment	ProgrammeManagingDeanery
curriculum_membership	vwCurriculumMembership	ProgrammeManagingDeanery
person_owner	vwPersonOwner	Owner
programme_rotation_membership	vwProgrammeRotationMembership	ProgrammeManagingDeanery
programme	vwProgramme	ManagingDeanery
programme_curriculum	vwProgrammeCurriculum	ProgrammeManagingDeanery
programme_membership	vwProgrammeMembership	ProgrammeManagingDeanery
programme_post	vwProgrammePost	ProgrammeManagingDeanery
programme_rotation_post	vwProgrammeRotationPost	ProgrammeManagingDeanery
trust	vwTrust	DeaneryLETB

Revalidation:

A full sync from TCS -> Reval is needed to update the programmeOwner
UI repo doesn't use "Health Education England" prefix outside the specs

ESR

In ESRExporter db, there’s a Deanery table which look similar to local office table, do we need to care about it?

Traine Self Service (TSS)

We'd break 3 things without parallel changes done

Support links for the FE are mapped by hardcoded local office name
NTN generation is part determined by hard coded local office name
Our pilot filters use hard coded local office names

Everything else shouldn't care too much assuming IDs won't change.

The biggest risk for us is the pilot filter, we could potentially miss sending notifications during any period the values don't match.
We may need to update the code to match on both sets of values to cover the migration period.

Downstream reporting & dashboards:

Local Office Name is used extensively in downstream processes mainly in three areas: categorising aggregates, mapping and filtering. Designated Body Name is not.

For the categorical use, these should just update and it will not be a problem.
With mapping and filtering, these will need to be updated using the new names for them to function. These will include SQL scripts and Tableau reports but also systems such as Leave Manager and the Leave Manager ETL and London’s downstream processes which pull London specific data into their own systems (not sure exactly what these are).

It was agreed with the NDW team, data leads, London, etc, that there will be advance warning given with a timescale of when these changes will take place.

Leave Manager (Hicom) have not been contacted as far as I know so far so will need to check with them whether they can just accept the name change in their system or whether they need to do some work.
The Leave Manager ETL will need to be amended as it uses the Local Office Name as a filter.

Old repos:

- do we want to ignore them?

TIS-GMC-SYNC: DbcToLocalOfficeMap class
TIS-CONNECTION-DISCREPANCIES: DbcToLocalOfficeMap class

Local office & designated body name change