I want to make an auto-expiration system.
In my case it has to be: an account sign up, then it’ll expire in a month. How can I set this ”timer”? How can I make the thing (user account) get deleted because of this expiration date system from the DB?
Don’t have any idea how to do this.
Thank you.
We can talk about HOW you can do this… But first…
WHY would you EVER need to do this? Why WOULD you ever do this?
A user signs up with your-dumb-site.com. They do nothing. They never come back.
Why should you delete them automagically? They already agreed to your terms-of-service. They already agreed to your privacy policy. They’ve not asked you (nor taken any other action – such as clicking a “DELETE MY ACCOUNT” button) to delete their account. Why on earth would you delete their account?
Do tell.
Because the site concept includes these accounts that expire.
And, again… WHY?
They’re not taking up any appreciable space in the database. They ain’t hurtin’ nobody. Why should we delete them?
Because if they pay for something, then it’ll expire within a period, and they won’t access to the site.
Do you have the solution?
Oh wait… let me guess… the concept of self-deleting accounts is what we’ve all been waiting for? This is the feature that’s going to set the world on fire? Is that it?
(Spoiler alert: What you’ve envisioned is not a thing. Try again, Player 1.)
Snapchat has this. And its annoying to developers. It won’t last. Because, developers. Don’t piss off the developers. Don’t do this. You’re facing enough of an uphill climb. Don’t make the incline steeper.
Are you here to joke/troll me, or to help me?
Because if you’re joking, I’m the most playful person in the world, but not when I’m working.
Instead, if you’re trying to help me, you aren’t, because I have no answer to my question.
I am still looking for a solution if anyone has.
Hi @debemghf,
once user signed up or signed in to the system, store the last login date and time to separate table called “User Last Login” and run the workflow to check the last login with current date and time, it reached then log out the user from system. store the expire month number in separate table.
Thank you for your response @manikandan
I have the field ”creation date”, could I use it as ”starting date”?
Hope I explained correctly.
Hi @debemghf, happy to help here.
The best way to achieve this is with API Workflows. Heads up, you’ll need to be on a paid plan for API Workflows to work in your app.
First, enable API Workflows: Go to Settings > API > Expose Workflow API. Now, you’ll see “API Workflows” available in your page dropdown list (upper left). Here’s a video that will help walk you through this further: https://www.youtube.com/watch?v=RbQCCZfdzes
Then, you’ll need to create an API Endpoint (in this new API Workflows area). Name it whatever you want - something like “expired-account.”
Add a parameter to the endpoint called “user,” and the parameter type = User
Add an action for this workflow: Delete thing > Thing to delete = user (parameter)
Now, in the signup workflow (from whatever page that happens on), add an action at the end “Schedule an API Workflow”:
So, when a user signs up, it will schedule the API Endpoint to run in a month. At that time, it will delete the account.
Now, very important - you need to be able to CANCEL this workflow if the user wants to keep their account active before the expiration date. So, best thing to do is SAVE the scheduled workflow ID. In the sign up workflow, AFTER the “Schedule an API Workflow” action, add an action to Make a Change to Current User: Expiration API ID = Result of previous step. “Expiration API ID” should be a text field under the User type.
Wherever you decide to use to trigger this cancellation (maybe the completion of a user profile or the confirmation of their email address), you’ll want to run the action “Cancel a Scheduled API Workflow” and provide the Current User’s Expiration API ID as the ID to cancel. Here’s a video on the API IDs: https://www.youtube.com/watch?v=ZoPQd2z_pBM
I hope this helps!
Gaby at Coaching No Code Apps (formerly Coaching Bubble)
Courses & Products, Tutorials, Private Coaching, and High-level Development
This is one way to do it. But now that we know that @debemghf is not actually seeking to delete a User (which, again, there’s no good reason for us to do except when the user themselves requests it), but is actually seeking to understand HOW they can have a concept of a “subscribed” User and enforce a subscription expiry, we have a lot more options.
The question here is not really, how do I delete the User after some time period. The question is more basic:
How do we control access to subscribers-only page?
First, what does it mean to have a user subscribed to some service we provide? They’ve taken some action (like paying us maybe) that grants them access to some feature or service.
So, when they take that action, we need to record that. We can, of course, create a Subscription object (if our site/services are complex and there are different things or tiers that a user might subscribe to) and attach it to the user. Or, if our site/service is simple, we might just record that event on the User record.
What should we record? The only thing we must record is an expiry date (this should be an actual date object, a date/time). Let’s assume the simplest case where we only offer one type of subscription. We can have a field, of date type on the User object. Let’s call it “Sub Expiry Date”.
When the user “subscribes”, we record this event by setting the value of User’s Sub Expiry Date to the date/time that the subscription expires. For example, for a 30 day subscription: Make changes to User, field “Sub Expiry Date” = Current Date/Time +(days)30.
Once we have this, we can always, at any time, detect whether the User is “subscribed”. And we can detect 3 unique states:
The User has never subscribed: If User’s Sub Expiry Date is empty
The User has an active subscription: If User’s Sub Expiry Date is not empty AND Current Date/Time < User’s Sub Expiry Date is true
The User has an expired subscription: If User’s Sub Expiry Date is not empty AND Current Date/Time < User’s Sub Expiry Date is false
Note that we do not need access to API Workflows or to expend any server-side resources to check this. (Now, perhaps we should, but we do not have to.) When the user shows up to our site and logs in or tries to go to some valuable (subscribers-only) page, we simply check this one condition:
Current User's Sub Expiry Date is not empty and Current Date/Time < User's Sub Expiry Date
What do we do on our subscribers-only page to control access?
In the case of a subscribers-only page: All elements on this page should be hidden unless this condition is true. So, just like any “admin”, or “Logged-in User-only”, or other “controlled access” page, we design the page such that all elements are hidden by default. (Typically, by grouping all of those elements in a group so we only have to unhide/show one thing.)
Then, we have at least one Workflow on the page that fires on “When page is loaded” with the “Only when” condition Current User's Sub Expiry Date is not empty and Current Date/Time < User's Sub Expiry Date. This is the “hooray, you’re a subscriber!” workflow. So we can show the hidden group. (Element > Show > the hidden group) And now the User goes on about their business on the page.
If a User does not meet this condition, they will just be stuck here on a blank page, unless we do something else. So, we can for example:
Handle the case of a User who has never subscribed: We need another When Page is Loaded Workflow, this one “Only when” Current User's Sub Expiry Date is empty. We can display an alert (“You must be a subscriber to view this page.”), show a pop-up (“Hey, subscribe today to get this amazing content!”, and/or redirect the User to a tout page for our service (Navigate > Go to page > our awesome tout page).
Handle the case of the User with an expired subscription: We need another When Page is Loaded Workflow, this one “Only when” Current User's Sub Expiry Date is not empty and Current Date/Time > Current User's Sub Expiry Date. We can do whatever we need here, like navigate the User to a subscription renewal page. We could get fancy if we want. Perhaps if the sub has only recently expired, we might show a nag pop-up, but let them get to the content anyway.
But eventually, we want to get them to re-up their subscription, right? When they do that, we update the Sub Expiry Date field to the new expiry date.
And there you go.
I have more to say about what we SHOULD schedule vis-a-vis subscriptions, but maybe that’s better for a video…
@keith
That’s absolutely the best solution. Yesterday, I made an Admin check on the Admin Control Panel page by myself, and that’s precisely what I did.
I’ll try to apply this system as you wrote.
I have some doubts about how to get the current date and confront with the expire date.
That’s because I read it fast.
I’ll apply it step-by-step, then by making mistakes, I’ll learn.
Thank you for your help.
@keith Okay, I did all and is properly working.
But I am stuck at the renewal part. How can the system understand when the payment is made?
Hey guys, still looking for a response.
Still looking for a response: How can the system understand when the payment is made?
