I have to admit, I’m feeling quite frustrated with a particular limitation in Softr and I’m hoping to find some guidance and potential solutions from fellow app builders.
As we all know, Softr has been consistently providing new advanced tools, taking our apps to the next level. However, I’ve hit a roadblock with a basic user account function: allowing users to change their email addresses. I understand that this may not be a common requirement for some apps, but it’s essential for my use case, and I’m disappointed to find that it’s not even on the roadmap.
For those who have faced a similar issue, how do you manage user expectations when it comes to changing their email addresses when they have a subscription? Have you found any workarounds or solutions to overcome this limitation, without making your app seem unprofessional?
Currently, I have created an overridable User ID in Airtable that enables users to create a new account and override their new user ID with the old one. I can automate that process and this way all their old records are tied to the new account. However, I’m concerned about the Stripe account not being attached and the inconvenience for users having to resubscribe and the timing of when to do it for someone on an active subscription; the very reason for the limitation.
Softr team, is there any plan to address this limitation and provide users with the option to change their email addresses? I’m sure you understand that having a unique, app-specific ID for users would solve this issue. Your input would be highly appreciated, as this issue affects my ability to release my app.
In summary, I’m looking for suggestions on managing user expectations and finding workarounds for the email change limitation in Softr. Any input from the community and the Softr team would be greatly appreciated, as I’m genuinely concerned about having to scrap my work in Softr and move on to another platform.
Additional context - this issue impacts two apps that I am building, but the one that is hit harder is tied to the user’s work email address. As they change jobs, they need to change their email.
Hi @artur , I think the broad use case is that anytime a user wants to change the email associated with their account, they can do it without having to create a new account.
For me specifically, I have members that will have an auto-renewing subscription paid via Stripe. In some cases, my users will be required to use an employer-based email account, but if they leave the company, they should be able to maintain their subscription and be associated with my application.
But this is just one case, people need to change their email address for several reasons, and it is awkward to make them create a new account for something like an email address change. Plus, I am not even sure how I handle transferring their active subscription … do I have to cancel it and make them sign up again? Do I find a way to let them wait until their subscription would have expired? I have a few other ideas, but they all seem clunky.
For your question, “would go and update in connected/airtable/googlesheet/stripe etc” - Yes, that would be ideal, but I don’t know if that is allowed/required for Stripe specifically. However, in my opinion, the idea of email acting as the primary key for a user is troublesome to begin with. It would seem to me that each user should have a key or token that performed that role e.g. each user gets a code such as ABCDE-97E64Z21 generated by Softr where the first segment is specific to the app and the second segment is specific to the user. Then changing the email was just another variable. If Stripe won’t accept this code as the customer ID, do they not allow the user to change their email address in some way that can be synced to Softr?
I get my users primarily and firstly through Online Travel Agencies like Airbnb and Booking.com. At the time of booking there is no email provided by the OTA other than an alias (like guestAresX@airbnb.com). However, we still want to give them access to the app right away so they can update their data (Name, ID, Passport Number, etc). For purposes of customer retention we would like them to be able to update the email to their real email so they could start using our app, instead of the magik link.