Reference:

update tables DBC & LocalOffice

1. Trust, Site table contains `localOffice` name.

2. `LocalOfficeContact` only contains the localOfficeId, so there's no need to update it.

Profile (User Management):

1. No need to update anything as it uses the designated body code instead of its name.

2. LocalOfficeToDbcMapper class. It's not used anywhere. – should we move it or update it?

TCS:

1. DesignatedBodyMapper class - this is also used for Reval sync

2. PersonOwner  - is populated by Sync service with Programme/Post owner and after that a person elasticsearch sync job needs to be triggered.

3. Post - owner is from LocalOffice

4. Programme - owner is from LocalOffice

NDW:

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

Revalidation:

1. A full sync from TCS -> Reval is needed to update the programmeOwner

2. 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?

1. TIS-GMC-SYNC: DbcToLocalOfficeMap class

2. TIS-CONNECTION-DISCREPANCIES: DbcToLocalOfficeMap class