Hi guys,
I have an element which I want to hide if the user has been signed up more than a month. So, after one month I am hiding the element, is this correct??
Hi guys,
I have an element which I want to hide if the user has been signed up more than a month. So, after one month I am hiding the element, is this correct??
No⦠that will hide the element when the User has existed for less than 1 month⦠which is the opposite of what youāre trying to do.
You need to use the opposite, i.e. When User's Creation Date +(months) 1 < Current date/time
ā¦although itās worth pointing out that the Userās Creation Date is not the same as the date they signed upā¦
So if you specifically want to hide the element when the User has been signed up more than a month youāll need to add another date field to the User datatype to store the date they signed up to your app.
Ah perfect, thanks @adamhholmes and thank you for pointing out that the Userās Creation Date is not the same as the date they signed up, Iāll work around that.
The Userās Created Date does appear to be the same as the date they signed up (see below). I think this is all I need, or am I missing something?
The Userās Created Date does appear to be the same as the date they signed up (see below). I think this is all I need, or am I missing something?
Yeah, obviously if the User signs up on the same day they were created in the database, then theyāll be the same day (but not the same timestamp)⦠but in reality thatās very often not the case (although I guess it depends on how you attract users to your app)ā¦
A User can be created in the database up to 3 days before they sign up, so in reality there will very often be a difference of 1-3 days between the User created date/time and the date/time they sign up for your app.
So it depends on what you need to do and if a discrepancy of up to 3 days is an issue for you⦠if you donāt need to be that accurate then you can just use the created date (it will never be more than 3 days out from the sign up date)⦠but if you need to be accurate then a separate field to store the sign up date will be needed.
Ok thatās fine because a discrepancy of up to 3 days is no issue in this particular case. Thanks again for clarifying
Fair enough, if thatās what works in your use case then great⦠I might urge some caution with that approach thoughā¦
Iād consider it a fairly important (and very simple) thing for any app to accurately store the date a user signed up, especially if there are any kind of legally binding Terms Of Use agreements between you and your users (which of course there should be)ā¦
If the date youāre storing for when that agreement was made is different from the actual date the user made the agreement (or worse still, youāre not storing the date at all), then for one thing it could potentially void any such agreement altogether, or at the very least leave you open to legal problems if there are any disputes raised about the agreement or the use of your app by the user.
Also, for GDPR purposes, Iād always ensure Iāve got some accurate way to know when a user signed up for my app, agreed to our terms of use, and gave consent to store their details.
We always keep accurate records of all user interactions with our apps (first contact, email sign up, sign up as a user, subscription created, subscription changed, or cancelled, etc. as well as records of all agreements of our terms, and updates to our terms etc.), partly for our own accurate record keeping, and partly to help with any disputes about payments, membership, or agreements (of which weāve had a few - especially from customers trying to pull a fast one saying then never agreed to certain things)⦠if we have accurate records to prove otherwise it usually prevents any further legal action from them.
Obviously, Iām not a lawyer, so donāt take any of that as legal advice (consult your own legal team for that), but it might be worth thinking about (especially for something so simple to implement).
Thatās great information, you make some good points thank you, I will add a field to record the exact signup date. Out of interest, what is the āCreated Dateā for if not for the date of the accounts creation?
Something isnāt working with this setup, I wonder if you can spot where I am going wrong⦠bare in mind, I will soon remove the āCreation dateā and replace it with a custom āsignup up dateā field as per your advice.
If I have a text element which says āYou are on your trialā, I can successfully change that to āTrial expiredā using the condition Current User's Creation Date +(minutes):1 > Current date/time
so the issue is with the backend setup.
The āUser Created Dateā is the date/time the User record was created in the database (i.e. the moment they first landed on a page in your app)⦠if they donāt sign up, then theyāre stored as a temporary User for 3 days before being deleted⦠so if they land on your app at 10:13am on Saturday, that will be their āCreated Dateā. If they then sign up at 9:25pm on Sunday, that will be their sign up dateā¦
- Iāve created a back end workflow to handle this and (as a test) I have set it to change the database field after 1 minute, but it never changes the field?
No, you havenāt⦠it will change the trialExpired field to āyesā the moment that workflow is triggeredā¦
How are you triggering/scheduling it to run?
Ah that makes sense, thanks.
No, you havenāt⦠it will change the trialExpired field to āyesā the moment that workflow is triggeredā¦How are you triggering/scheduling it to run?
I didnāt know that I needed to trigger it - I have no experience working with the APIs in this way as you can tell! I will do some research.
Yes, you need to trigger it using a āSchedule API Workflowā actionā¦
Presumably, youāll want to do that in whatever workflow you run when a User signs up, and schedule it for one month from that date/timeā¦
All sorted! Thanks @adamhholmes