I didn’t see anything outlining this specifically so I thought I’d ask here. I’m working on a subscription-based web app. What I’m looking to do is allow users to use the app and create profiles only when they are subscribers. I’m planning on doing a free trial, then charging.
I see in stripe I’m able to do a trial period which is great, I’m just confused at how I can limit user access once the trial period is over. I saw a post about limiting screen access based on subscription, would it be similar to that? Any guidance on how to set it up would be much appreciated.
If you’re intending to offer a free trial, let anyone sign up for an account.
In the Users collection, add in a few extra fields.
Free trial (true or false)
Free trial expiry (date and time)
Active subscriber (true or false)
By default, when a user signs up, free trial is set to TRUE, and the free trial expiry will be “Current Time + 14 (days, for eg.)”, and active subscriber is set to FALSE.
Add an action to the other screens (not components or anything, just select the SCREEN then add an action) and send users to the subscription page. Set the condition to sometimes, when Current Time is after free trial expiry date and time. Another condition is if the active subscriber is FALSE. This is to address users whose subscriptions have expired.
When a user pays for the subscription, set the “active subscriber” field to TRUE.
You might also want to set up Zapier for when users’ subscriptions have expired and they didn’t renew. When that happens, Zapier should set the “active subscriber” field to FALSE.
Hey @vancewong , thanks so much for this response. This is exactly what I was looking for, so now I don’t need to require credit card to sign up which was my initial workflow. I haven’t tried anything with Zapier just yet but I think that is a great idea.
One issue I ran into is the action on the screen to direct to subscription page, I don’t see how to make more than one condition. I can set current time after free trial, but wouldn’t that also make it so subscribers can’t see the screen? If I do two separate conditions would the system read them as AND instead of OR?
Hey @jjking, you should have a home screen that’s visible to anyone, whether they’re subscribed or not.
When they navigate to the next depth screens, ie. any screen accessible from the home screen, then you set a condition - if current time is after free trial period, send them to the subscription screen.
Now, to prevent subscribers to be navigated away, when they do subscribe, remove the expiry date of the free trial period. My suggestion would be to set it to empty or even add a month (or however long the subscription is).
So the free trial period can be named as “subscription expiry” instead, and what the free trial does, is that it just adds 14 days to the current time when the user signs up for it.
The Stripe component for subscriptions should add for eg. 1 month to the expiry date every time the card is charged. And I think you would need to set up Zapier for this (ie. when Stripe payment is successful, add 1 month to the expiry date).
The Zapier part I’m not quite sure but there should be parameters to differentiate each user and their subscription both on Stripe and your app. You can consider adding a field (user ID) that is only visible internally for you to easily identify users.
Thanks @vancewong I’ve almost got the first part worked out, not the Zapier part just yet. One question I had is, do you know how to remove the expiry date for the free trial? I tested putting in 0 in the database and it made it 01/01/2000. It won’t let me type null or empty.
Another issue I’m trying to think through, is if I delete the trial time, then what happens when a user unsubscribes? Should I also make a setting to input a date in for the trial when they unsubscribe?
I like the idea of the Zapier adding 1 month every time the subscription is paid, but then that messes with something I set up saying you have X days left in your trial. I can get rid of that but I think the easiest solution would be to set trial expiry to null.
When a user signs up for a free trial, set the expiry date as current time + 14.
When a user signs up for a subscription, set the expiry date as current expiry date + 30.4375 (365.25 / 12).
For the countdown of subscription days left, use magic text to pull the expiry date. Date magic texts are formatted as “Relative” by default (eg. in X days), so you’re good.
As for Zapier, it can get quite complicated in terms of the logic, but there should be tonnes of tutorials on the internet, since Zapier is a very popular product. But if cost is a concern, you can look at Parabola or Integromat, both of which work the same, but less user-friendly
What I haven’t been able to figure out in Zapier is how to tell Zapier which record to update in Adalo. Apparently there is a Record ID that Zapier needs in order to know which record to update. Such Record ID is supposed to be the last number in the record URL (when you navigate your collections in the editor) however, I don’t see that recorded anywhere in Zapier from the info received from Stripe.
When a Stripe transaction happens, I can’t find a way to know from that action, which Adalo user did the action in order to update such user’s data. I guess my Zapier should read: When New Suscription from Stripe, update in adalo users status. When Canceled suscription in Stripe, update user’s status in Adalo. The first one I can do directly in adalo (when payment goes through update user), and for now I’m setting up an email when user cancels so I manually change such user status, very very bad but can’t figure out another plan for now.
I don’t have experience with this (maybe not yet, at least ), but I think one workaround is to add another field in both the users and subscriptions (or payments) collections.
You can call it objectID or something, and this should never be referenced by anything other than Zapier.
Then your users collection can have one to many relation with subscriptions/payments collections.
This is something we need to fix from our end but also a problem that hopefully becomes less important when we have our internal API available to use for collections.
@anon78309838 do you guys have a timeline on that? Debating if I should mess with building something for subscriptions or waiting till you have a better workflow.
), but I think one workaround is to add another field in both the users and subscriptions (or payments) collections.