We have several in-house apps for employee use. They are different enough from each other that it doesn’t make sense to combine them into a single app. I’m trying to unify the users table for all of them and I’d like it to be current employees. It also would be necessary for the staff users table to be a Glide table to share across the different apps.
My question is how to deal with former employees. I set up a deactivation action - delete the row in the users table and add it to an inactive staff table, but I realized that orphaned rows in at least one of the apps.
I don’t know how to only allow a filtered group of the users table to have access and user profiles don’t work with computed columns. When a staff member joins or leaves, I’d like to be able to make that update in one place and have all the apps synced.
Not sure how rows are being orphaned…is it because you’re making relations via email address or rowID?
Two possible options:
Use a separate glide table for whitelisting. Keep this table up to date with those that can sign in. This way, you don’t need to delete anyone from the users table, but it will effectively double the amount of user rows in your app.
When you deactivate a user, don’t delete the row, but simply change the email address of the user. This way, the data is still there, but the user won’t be able to sign in.
Would have a template column of something like “archived+abc@example.com”. That way you know that account originally belongs to abc@example.com, just in case you need to revert it.
The only issue with that is that it can break relations to other data, if you’ve been using emails to create relations (another reason why it’s better to use RowIDs for relations).
I generally use your first option…
When a new user is added, I’ll send a webhook and then use the API to add the user to the whitelist table, and set their role at the same if (if roles are used).