I wrote a backend workflow to cleanup related records in a database when a user account is removed. These are all tables in my db that can contain user-related records which get orphaned once a user account is deleted:
The conundrum though is it seems the backend workflow that fires doesn’t have access to the prior User object once it’s deleted so without the user record the queries for the user’s related entries all come up empty:
The downside of this approach is redundancy (you might end up running more delete actions than you need to), but a bit of extra WU never hurt anyone and it makes it easy to maintain.
There are many other approaches I look forward to seeing!
Thx @georgecollier & @animisha45 for both of these suggestions. It would seem that both necessitate only ever deleting users via a custom admin UI in your application. Is that the case?
I’ve just been deleting users directly via the Bubble user table which is why I was hoping to use a db trigger to do a cascading delete of related records.
My logic was to “Delete List” for each related table where the list was populated from a query that just pulled up all that user’s records:
I tried both User is empty and User account doesn’t exist. That did not work for the catch-22 reason I mentioned above.
Maybe the answer here is in fact to only ever delete records via an admin UI that I control and just make it so the order of operations deletes the related records first and the user as a last step as you’re both proposing.
I would be curious to know though if anyone has figured out a way to do this keyed off of a db trigger that runs upon User delete, or if this approach is just inherently infeasible given the order of operations. thx again.
But the same issue I’m having would persist in that scenario: the problem is once the user record is deleted, any attempt to query related tables for that user fails because it’s a deleted thing at that point.
That’s not a good practice in general. If you delete the user from editor, you will have to ensure all related data types and database are also deleted and that can become cumbersome.
I am not sure what the reason for deletion is, but having either the ‘delete your account’ on user dashboard or admin control can ensure a proper workflow.
You can trigger backend workflow from any page using scheduled workflow.
You could think that if a user has related data, you can create a trigger such that when the related data is deleted you run the series of actions to delete all related data and lastly delete the user…this takes care of the issue you have when the user is deleted the system no longers see the user and so doesn’t find the related data.
So if every user has a profile, you can create the trigger for when a profile is deleted, then delete all the related data to the user and lastly delete the user. From your editor you can then delete the profile rather than the user.
yes, both the suggestions you’ve had so far require you to create the UI in the application and run the schedule actions from the application, and neither are setup in such a way that you can delete from your editor as you want.
I ran into a similar problem so I created an option set called STATUS. The set contains Active and Deleted (I ended up adding other status like blank and new for other functions and conditions)
Then on the user add a field using this option set.
Now when the interface “deletes” a user it actual is just changing a thing from active to deleted.
On the page you can add a condition to hide when status is “deleted” to show an instant appearance of an artificial deletion .
The on the workflow I have a database change api that looks for a change on the user with a condition looking at if status is deleted.
When this is the case run your actions to delete. What you need.
What’s nice about this is you can delete from anywhere with one change to the thing’s field and the magic on the background all handles it. So later in your app development if you add another case where you will have orphan you don’t have to change all the workflows and just change this api.
Last added tip you can delay the api by 1 minute or something and allow an undo button which changed the status back to active. The API still runs but I have conditions on the API to look at the database to see if it’s still in a status of deleted.
Yes this is a great suggestion.
So it accomplishes the goal of keeping it simple to delete users from within the Bubble db user app data UI while solving the conundrum of needing to delete the related records before removing the user.
Will use this. Thanks so much @chris19.
