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:

I made it as a database trigger with this logic:

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:

That seems like a Catch-22 if it’s true… How do others handle automated data cleanup after user accounts are deleted?

I have one API workflow per data type that needs to be deleted. This API workflow takes a single parameter that is the thing to be deleted.

I do not use triggers alone to delete things, because triggers can’t trigger other triggers.

Here’s a real app I’m working on.

When a job seeker is deleted, I delete a list of references and a list of work experiences.

As a Reference also contains a Referee which is another associated data type linked to the Reference, I handle that in the deletereference workflow.

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!

I usually go with a backend workflow whoch takes care of deleting the related data. And as the last step, delete the user.

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.

No, why would it? You can schedule the API workflow from anywhere in the app, front-end or backend.

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.

Can you share what the triggering logic looks for that Custom workflow you showed above? If not a db trigger then how are you invoking it?


(because not all users are job seekers, I will have another custom workflow for deleting different user types)

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.



Source link

Leave a Reply

Your email address will not be published. Required fields are marked *