Hi folks - I’d like to set up a workflow where a monthly subscription user is given a fixed number of times they can use a button in a month (i.e allowance of 50 times), once they hit their usage allowance, the button should be unclickable until their new monthly subscription begins and their monthly allowance resets. Can this be done, and how? Would love your help!
Add a new field to User, call it “Credits” or something. Make it a number. Then everytime they click it have it “Make a change to a thing” User’s Credits and do the current user’s credits - 1.
Then add a conditional to the button so if the Current User’s Credits is 0 then the button is not clickable (and maybe add some extra formatting so it’s greyed out, etc).
There’s a few ways to reset the credits at the start of each month. You could have a backend API workflow scheduled to run every month that resets all users credits.
That’s a fantastic solution - many thanks Tyler! Forgive the silly question but could you please give me some guidance (or a link perhaps) on how one could set up the backend API workflow? I’m quite new to bubble so still learning. Thanks ever so much!
If you’re on a paid plan then you can enable backend workflows which are workflows you can run server-side. So they can run on a schedule in the background without the need of a user to actually trigger them. Are you on at least the personal plan for your app?
Hi Tyler - thanks for this and yes I’m on a personal plan at the moment.
Okay how many users do you think you’ll need to reset credits every month? is it under a 100 users or could it be over that? If its over 100 then it’s a slightly more complicated set up, if its under 100 then you can set up a “Make changes to a list of things” action and it’s pretty straightforward.
It’d be more than 100 users (we hope!). Really appreciate the help!
Okay this will appear convoluted but I think this will work, see if you can re-create from these screenshots:
First create a new API workflow, make sure you make the type User and check the list, and optional.
Then you’ll be searching for users, subtracting the list of users we’ve already processed (0 since it’s the first time we’re running this) getting the first 50 results, setting their credits to “50”
Then we will re-schedule this exact workflow for 1 second in the future, but we’re passing on the list of processed users + the ones we just processed in step 1.
There’s also a conditional to only continue the loop if there’s users left in the search to process.
Step 3 has the conditional when the users left to process are 0. It reschedules this workflow for the current date/time + 1 month, then rounded down to the nearest day so it schedules it at time 00:00. It also passes on the empty list of processed users.
In theory this should work for infinite number of users. Of course for testing change that that step to Current date/time + 2 minutes or something (and get rid of the rounding operator) so you can use some credits, then know it will schedule itself in 2 minutes to reset it automatically.
Also do this in the backend workflows, if you don’t have backend enabled go to your app settings and enabled it first
If you have an admin screen or something, put a button on there to schedule the initial workflow to start the whole process
You are a lifesaver, Tyler! Not going to lie, it’ll take me a few tries to get this right but I really appreciate your help and guidance.
Hi Tyler - i’ve completed the first part of your advice (i.e. creating the credits field, changing a thing, reducing it by -1, and updating the button with a conditional to ‘being unclickable’ when the credits hit zero) - so massive thanks for that. On the API backend workflow, is this the right syntax for step 1 - i.e. “Search for users: minus processed users:items until #50”? Please see the screen shot.
Hi Tyler - these are the screen grabs from my attempt to implement the backend workflow. I’m not sure if I’ve got the syntax right. Would be great to get your views. Thanks in advance.
Hi Tyler - each user will be subscribing onto the platform at different dates - so the workflow for the conditional would need to include a counter that tracks the number of days left in the subscription month. So when “Days in Subscription Month” evaluates to 0 AND the subscription is still “active”, then the user’s credits would reset to 50 at the start of the new month. Would this conditional go into your step 3?
Yep those screen shots look correct but now this might change a little bit since you’re saying they are all staggered when the credits reset.
Side note we might want to consider implementing: Are all users going to be reset to the same 50 credits? Or could that be different for each user?
If users are signing up at different times, you’ll need to add a new field to User called something like “Subscribed date” and make it a date type. Then when they subscribe in your app have it set that date to Current date/time.
Do you have a reusable header on your app that’s on pretty much any page? We could have a conditional run on page load to check if it’s been over a month and it can actually trigger the user’s credits to reset themselves instead of having to run a search every day (since users could sign up at different dates now, it would have to run every day)
Thanks Tyler. On your question, everyone has the same amount of credits (in terms of the reset) - keeping it simple in the early stages. Good idea on the ‘Subscribed Date’ going into the subscription workflow. Haven’t got a reusable header on every page - the header is on the index and the ‘about us’ page but i’ve gone for a more bespoke option on the app dashboard.
Okay so just for now on your main page that you think everyone will go to:
Make a workflow and it will be “On page load” and make the condition "When current user’s Subscribed date + 1 month < Current date/time. Then the step 1 action will be “Make changes to Current User” and set the credits to 50. And also update the “Subscribed date” to Current date/time
So when a user loads in and their last refill date + 1 month is still earlier than current date/time (more than a month ago) , it triggers a reset of their credits.
Then delete all the backend workflow stuff I told you about because none of that is needed now.
Now that I think about it’s not really a “Subscribed date” it’s more like a “Last refill” the field should be called.
Later you would want to move this “On page load” logic to a reusable element on every page, so any page they visit will trigger this check for their last refill date
Great stuff, Tyler. Quick reflection, though. If you set up ‘Subscribed Date’ as Current Date/Time, this would make it a static snapshot in time which would make it difficult to track dynamically. Ideally, we want a counter to dynamically track the number of subscription days left in any current subscription month and then reset the user credits when the number of days reaches zero. This is the expression I’m using to measure the number of days (i.e., Current Period Subscription Days) left in the subscription (Current User Stripe Subscription’s current period ending date: rounded down to day - Current User Stripe Subscription’s current period starting date: formatted as days). Another potential alternative would be to set up the ‘On Page Load’ workflow as you suggest, but make the condition ‘When current user’s Current Period Subscription Days = 0 and the user stripe subscription is active’, step 1 action would be to make changes to Current User and reset credits to 50. What do you think?
I’m not sure if other subscription services necessarily count down days in the background, instead I think they just store the start date of the month’s subscription and on a daily check they do the math to see if the remaining days is 0
If you wanted to check a users days remaining you could just store the date of when they subscribed (like you have it now), then on screen do the calculation of Current date/time - Subscribe date. just on demand when you need it on an admin screen or for the user on their profile screen.
But it’s different than the 1st backend workflow I showed you because now you’re not monthly resetting credits 50 users at a time. Now you’ll need to do a daily search for users with an active subscription, and calc the remaining days for that user, if it’s less than or equal to 0 then trigger a reset of credits.
This topic was automatically closed after 70 days. New replies are no longer allowed.