Modify data of thing based on creation date

[josh7]

Hi guys,

I’m building a simple job board and would like jobs to be automatically removed from the site after a certain period of say 30 days. I don’t want to delete the jobs completely so my idea was just to have a field called “status” that would change from “live” to “expired” after 30 days, and my repeating group would only show “live” jobs.

The part I can’t work out is how to have the “status” being automatically modified to “expired” after 30 days. I feel like it needs to be a site-wide workflow rather than at page level? Does anybody have any ideas?

Thanks so much

[andrewgassen]

You’ll use scheduled API workflows for this.

[mishav]

A passive alternative is to have an expiry date instead of a status, and compare the current date to the expiry date.

[josh7]

Thanks for the advice. How would I do this in terms of setting up the workflow? Thanks again

[manikandan]

“scheduled API workflows” is not possible if your in Huppy plan,
please review the pricing at Pricing | Bubble

[andrewgassen]

To make the comparison work, won’t you still need some sort of action to trigger the comparison in the first place?

[josh7]

Seems like I will need to use a schedule API workflow but I’m pretty stumped by how to actually do it.

Would I add the action for updating the status in the API workflow menu? And I’m not sure where I should actually trigger this as it’s really a site-wide function and some jobs would be added directly to the backend in Bubble, rather than through a specific page on the site. So far, I’ve got this in the API but I’m not convinced I’ve got this right?

[keith]

@mishav has the right idea on this. Don’t waste workflows on this. Just don’t display jobs that are 30 days older than their creation date.

That is, you can always algorithmically get “expiration date”, right?

Now, it might be wise (hard to say if there’d truly be any benefit to this) to set a date type field (“expiry date”) on the job thing when it’s created that is current date time:+days 30 so that you don’t have to compute that over and over in your search criteria.

But you need not schedule the thing for deletion or even create some automated workflow for that. Database getting full? Go in and do a bulk API workflow from the data tab to cull your old things. And you can do THAT at a time when you don’t have a bunch of users online.

Once you get a sense for the patterns, then you might set up some sort of auto delete plan. But this is one of those, cross that bridge when you get to it things, right?

Just build your thing and deal with the ops type stuff as you have the time and necessity. I can see a lot of good reasons to keep your historical data around for longer than 30 days and it’s not like job descriptions take much space. It’s just a bunch of ASCII.

[josh7]

Ah, that makes total sense. Thanks for all the info. That’s really useful!

I went with the 2nd option of adding an “expiry date” field as I felt it would make it easier to let users login and renew jobs at a later date.

Thanks again

[keith]

Yeah, exactly - that’s a very good reason to keep things around!