How to know if a delete operation was successful or not?

Hello all.

I have been looking in the forum for an answer to the following question, but I haven’t been able to:

How to know if a delete operation was successful or not?

It looks like a delete operation does not return any result (unlike create and update operations).

Is querying for the (deleted) item/s the only way to figure out whether the item/s was/were actually deleted? Seems like a “waste” of computing time and resources, doesn’t it?


Good question. While I agree it’d be nice to have some sort of confirmation, I haven’t had occasion to doubt that a deletion operation has occurred. (Bubble has consistently performed the delete action as intended).

Provided that your user is able to view the record (ex. deleting a cell from a repeating group), the delete function should work flawlessly. However, if you have some underlying privacy roles that could cause a hiccup (ex. a referenced list), then it’s possible for a delete action to fail. (You can circumvent this with an API workflow that ignores privacy roles).

Keep in mind, when a thing has been created/updated, there is a specific object to refer back to. But, once something has been deleted, (theoretically), there is nothing to refer back to, “Ex. your order for a hamburger has been deleted”. If it was still there, it would be a facsimile, not an actual data point.

1 Like

Hello @dan1. Thanks a lot for your answer.

I agree that Bubble normally has never failed to delete an item, but whilst it’d be good to know whether an item has been deleted to have a sort of guarantee that the item has actually been deleted, it would also be extremely helpful to control the order of executions of actions in workflows.

Right now, the only way to be able to execute action2 after action1 is if we can refer to action1 from action2. If action1 is a delete operation, right now there’s no way to refer to action1 from action2, so we can’t enforce action2 to take place after action1.

The only way I have been able to control the order of execution of the above mentioned example is if in action2 I look up the item deleted in action1. If the lookup fails, then I know the item was deleted in action1.

But as I said in my first message, this requires an extra lookup, which I think is a bit of a waste in terms of time and resources. Especially taking into account that every database I know returns some sort of acknowledgement after a delete operation (so Bubble could just return this acknowledgement).


If you’re talking about operations in the page, note that Delete operations do execute synchronously. For example, the following workflow:

Causes a progress bar in the browser. Step 2 (which simply sets an icon to visible) does not start until the progress bar is done (the object is deleted). So it seems that, at least client-side, one does not need a “results of step 1” to enforce synchronicity.

[I can’t say for sure if this is true of an API Workflow / server side, but I’m guessing it is.]

But it is true that Delete (also Delete List) does not return a value that can be inspected.

If you really really need to check for object deletion the only way would be to snag the object’s unique ID before deletion and then search for that object and if that comes up null then, yeah, it no longer exists.

But, like @dan1, I’ve never seen a case of a requested deletion failing. So… not sure if this is something you should worry about?

(But even if you DO want to worry about it, Do a Search for Thing (constraint unique ID = some_id):first item isn’t such a big deal in terms of capacity hit.)


I can see many reasons to know when a thing actually is deleted, whether it is done server or client side. For instance, I need to ensure that a specific set of records (could be hundreds of records) is deleted before a replacement set is uploaded. My uploader checks for the existence of the records and if they exist, offers the user the option to delete them (using API WF). Since there is no way to know without checking and rechecking over and over whether the complete set of records are removed, my users could theoretically reload the download tool and submit new records before the old records are removed.

Having a conclusive acknowledgement would allow me to hold the user up until the acknowledgement is received preventing duplicates, or partial deletes or partial uploads.

I built a backend workflow that deletes a list of things stored on Thing A, and then deletes Thing A itself. So, similar to @miguel’s and @chris.charette241’s needs, I need to make sure that the list of things has been successfully deleted, before deleting Thing A. Since this is a backend workflow, I can’t use @keith’s solution.

So I simply put the “Delete List of Things” action in its own Custom Event, which is triggered before the Delete Thing A event. Custom Events ensure that future actions do not start before the Custom Event action is completed, and it works both for both frontend and backend workflows.

1 Like