Refactoring across multiple applications

this question is more of an investigation for finding a solution question and not implementation. OK, so i need to find a solution that will manage an entity across multiple applications. The current behavior is this when an employee leaves the company it is still kept it the DB's of all applications (all of our applications are internal). He/She however is at some point deleted from the Active Directory. I need to find a way/ solution that can be applied to all applications that will manage the ex-employee (basically erase him/here from all of the DB's where appears).

I thought of the following solutions :

Another solution would be the following Create files(XML, txt, whatever) based on User Info Tables for all DBs - this file will contain both active and inactive users Create a file from the AD (XML, txt, whatever) this file of course will contain active users
Using the AD file compare it with all other files best if we could use parallel programming here, access the AD file at the same time with all other files. The structure of the files should be simple and similar - only needed infos required to be contained.

2nd

Create a DB with one table Create the table that stores all user information (this is taken from AD) The schema of the user info table should be simple
ID | AccountName | DisplayName | Email | IsActive(NULL) | IsGrupe

Create a task that manages this user information table (updates the table when the AD is changed) Create a triggering mechanism when a modification in the User table occur this will trigger an event across all databases that have user info related logic.

On a positive note: - not to hard to implement (if clear separation is needed then a console application will be created, separated of all other projects this console application will handle the logic to maintain the UserInfo table up to date - this is just an example)

On a not so good side: - the triggering mechanism i think it's going to be quite large and complicated since all DB's have different schema so it will be needed to be taken into consideration the relations betweens one DB entities

EX: UserApplication TBL: ID | appId(FK) | userID(FK)

the deletion of the entity (app or user with specific ID) will need to also handle the deletion of the UserApplication entity that refers that specific entity with that specific FK, but keep the other dependent entity within the DB

3rd

Create a new app / services that manages User related logic in this case the deletion/ insertion/ update. The idea behind the application is this.

The first time the application will run, it will populate the User Table with all AD's users

The schema of the user info table should be simple
ID | AccountName | DisplayName | Email | IsActive | IsGrupe

After the first run every time a new user is inserted, deleted, updated this will reflect in the table as well. If a user is deleted it will be put in a state of 0 on the IsActive field.

After all the business logic that manages the user table is done, we could use the webapi across all applications (of course only application that have user business related to them). This way a single UserInfo tbl is shared across multiple apps.

Down sides: - Complicated, Time consuming, Hard to implement - Massive architectural change across many applications, since UserInfo related entities and tables will not be needed. - Massive changes over the implementation.

On a positive note: - Depending on the direction that the project is going: 1. Either having one task to update the User Information table using the Active Directory. 2. Or somehow chain also the newly created app with the app that manages the active directory (any change related to a user should translate in changes over the User Info table), in which case there is no task needed the process becomes automatic.(at least i think it should) An event changing the AD will translate in a service being called (from the new webapi) depending that event -> -> lets say Delete -> the table will be updated (meaning i thing better to set the IsActive state but keep the user as well) , this will result in changes over all of the applications that use the User Info table - We could start using SOLID : Dependency Injection, Inversion of Control, and also refactoring the code (of course if have time and approved)

So this is what i could come up with, any ideas, better solutions, would be very helpful. Thank you