Stumped about users

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.

Any help?

Not sure how rows are being orphaned…is it because you’re making relations via email address or rowID?

Two possible options:

  1. 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.
  2. 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.
2 Likes

Hi Robert - thanks for the suggestions.

I was using relations on the Row ID of my users table.

So for option 2 would you just replace the email with a dummy email, maybe the same one for all the inactives?

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.

Makes sense, thanks for the input

Exactly. I do exactly as @ThinhDinh mentioned by creating a dummy email like archived_email@domain.com

1 Like

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).

In Settings > Data, you can delete all data related to a user (email address). Would that be an option?

1 Like

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.