I have trial users who are allowed to upload images to my app to test it out. If a user doesn’t end up subscribing, I want to delete the images and other data they’ve created after 30 days. This seems like it should be easy to do in a backend workflow, but I have a data type Artwork with fields “Creation date” and “createdby” and another data type User with field “subscription status.” I need to create a backend workflow that will delete things from the Artwork data type for all users whose subscription status<> “active” where the artwork Creation date is over 30 days old. I’ve hunted around the forum, but can’t seem to figure out how to create a search based on criteria from two data types. This would be trivial in a traditional database with a JOIN. What am I missing?
When the user initiates their free trial, use a scheduled API workflow and set the runtime to current date + 30 days. Also, pass the user as a parameter. This will run after 30 days. Inside this API workflow, add “delete a list of things.” and for the thing to delete, add “Do a search for artwork” and set the constraint to “created by = User.” Add the condition “only when the user’s subscription status <> active is no” to this deletion action. That’s it.
And if you want to schedule a separate workflow for each artwork individually, then you can perform the same actions when creating each artwork, and then, after 30 days, you can “delete a thing: this artwork.” and add “if artwork created by’s subscription status <> active” to this.
For anyone who comes across this, I was able to figure this out, and it seems pretty easy now that I understand how it works. I don’t like the idea of doing it on a per record case by scheduling an API for each new record created - it just seems like there’s too much room for something to go wrong and I don’t want a bunch of scheduled APIs pending all the time. (If I’m dumb for feeling this way, let me know)
I set up a backend workflow that I’m triggering manually for now, until I confirm that everything is working the way I want it to. This workflow searches for artwork that is older than 30 days, and who’s user is in a list of users who are not subscribers. It was the “is in” function that allowed me to do what I needed to do to search in artwork based on user subscription status. This is what it looks like:
Let me know if I can help you by providing addtional information.
You are, unfortunately! It’s just a queue. Each queued item has a time (or not). Bubble will try and work through the queue as fast as possible. If the queued item has a time, it will wait until that time to run, and then run as soon as it can after that time. If it doesn’t have a time (i.e it was scheduled to run at Current date/time), Bubble will get to it ASAP (usually within a second or so).
A to-do list of 1,000, 10,000, or 100,000 might seem daunting to you, but a computer just plods its way through them one by one.
Now, in your specific use case, creating a scheduled backend workflow for each artwork is definitely a bit silly, as you picked up.
This means:
If, 30 days from now, the Current user’s Subscription Status is not active, delete all of their images and other data.
So, in 30 days, we want to check if the user’s Subscription Status is not active, and, if it is true, delete their stuff. You can see how this now sounds like how you might schedule an API workflow:
- Schedule an API workflow to run in Current date/time +days 30
- Add a condition only when user’s Subscription Status <> active on the workflow itself
- Run various actions to delete their data.
Your current approach technically works, but it’s not optimal, and will fail at scale (not to mention you have a nested search constraint which will eat through WUs).
The approach I’ve described would cost like 1 WU or less to schedule a workflow for each user (only the cost to schedule the API workflow). Then, the WU for deletion would be pretty small too as non-paying users surely don’t have much data and it’s just a few searches and delete list of things…
Awesome - thanks for the feedback. I’ll try this approach. I think I still end up with a nested search though, because I have to check for the subscription status, right?
I truly appreciate the time you took to provide your response!
No, because your backend workflow will just take a single User, so you search for Artworks for the User in the parameter. You do one search for each user that requires deletion, rather than one search for each entry in your database!